Re: WebOTF Proposal: updated description and sample code

On 13 Aug 2009, at 23:26, Laurence Penney wrote:

> Thanks a lot for this code and spec, Jonathan!
>
> I have a question about the compLength field. The definition in the  
> draft spec is rather convoluted. If compression did not make the  
> table smaller, then does it *always* record the padded length of the  
> uncompressed table? If so, it's got two purposes which need to be  
> more clearly explained: 1) length of zlib-compressed data, 2) padded  
> length of uncompressed data.
>
> I do wonder about the utility of the padding bytes. Having any  
> padding allowed in the WebOTF file - in other words, allowing  
> anything other than a fully packed file to be valid - seems like an  
> opportunity for nasty things to hide, and makes validation &  
> calculation of the various length fields trickier (there are up to 6  
> zero bytes to track per table).
>
> Fixing compLength simply to record the zlib-compressed length (or  
> any number larger than the origLength to force interpretation as  
> uncompressed), and to enforce data packing would handily remove 99  
> words from the spec.
>

Packing successive unpadded, uncompressed tables is not a good idea,  
because this means that if a client wants to use the uncompressed data  
directly from the WebOTF rather than copying each table to a new  
buffer, it may find itself reading two- or four-byte values from  
unaligned memory addresses. This is expensive on some architectures,  
and is even be a crashing bug on some systems. The OpenType spec calls  
for tables to start on 4-byte-aligned addresses, and if WebOTF doesn't  
offer the same guarantee when storing uncompressed tables, it will  
force clients to do an extra copy operation before they can safely  
access the data with their usual code.

(The current Firefox test build wouldn't actually crash on such  
tables, because in practice it always memcpy()s the data into a  
complete new font buffer. But I don't want to assume that every WebOTF- 
reading client will always work that way.)

JK

Received on Thursday, 13 August 2009 23:54:49 UTC