W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: WebOTF Proposal: updated description and sample code

From: Laurence Penney <lorp@lorp.org>
Date: Fri, 14 Aug 2009 03:01:09 +0100
Cc: www-font <www-font@w3.org>
Message-Id: <8A0DA84F-9EDA-4FAC-8071-01130A4F8F10@lorp.org>
To: Jonathan Kew <jonathan@jfkew.plus.com>
Thanks for the explanation, Jonathan. I guess I need to see  
uncompressed data formats as being as memory-mappable as possible.

- L

On 14 Aug 2009, at 00:53, Jonathan Kew wrote:

> 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 Friday, 14 August 2009 02:01:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT