Re: WebOTF Proposal: updated description and sample code

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.

I quote:

> ... a tool creating WebOTF fonts MUST check that the compressed data  
> for each table is smaller than the original uncompressed data. If  
> this is not the case, it MUST store the table in uncompressed form.  
> (NB: it is possible for compLength to be larger than origLength in  
> this case, because the uncompressed table may have up to 3 bytes of  
> padding at the end which are not included in the origLength count.)


> OpenType Tables
> ===============
>
> The OpenType tables in the WebOTF file are exactly the same as the  
> tables in the original OpenType file, except that each table may  
> have been compressed by the compress2() function of zlib. Tables may  
> be stored in any order. There is no requirement for any specific  
> alignment of tables or padding between tables, except that when a  
> table is stored uncompressed (see above), it MUST begin on a 4-byte  
> boundary and be padded with zeros if necessary so that its length is  
> a multiple of 4. The "compLength" field in the table directory will  
> record the complete (padded) length of the table data, and may  
> therefore be up to 3 bytes larger than the "origLength".
>


- L

On 7 Aug 2009, at 23:35, Jonathan Kew wrote:

> Today I have implemented WebOTF encoding and decoding functions,  
> along with simple command-line tools to create WebOTF fonts from  
> OpenType (sfnt) files, add metadata and private data, and to access  
> these elements from the .webotf file. The code is available for  
> anyone interested in experimenting; see http://www.jfkew.plus.com/webotf/webotf-test.html 
> .
>
> That page also uses @font-face to link to WebOTF fonts, but of  
> course these will not work unless you use a WebOTF-enabled browser.  
> I have updated John's EOTL+ZOT patch for Gecko to support EOTL 
> +WebOTF, and builds of this new experimental version should be  
> available tomorrow. Meanwhile, the page has a link to a .zip archive  
> containing the WebOTF code, as well as the latest iteration of the  
> format description.
>
> Note that in the process, and following feedback from another  
> implementer (thanks, Karsten), I have reordered some fields in the  
> WebOTF header, as well as clarifying wording in at least one place.  
> So if anyone else has been experimenting, be aware of this change.  
> The new spec is dated August 7th, and is included in the .zip  
> archive along with the source code for the encoder and decoder.
>
> JK
>
>
>

Received on Thursday, 13 August 2009 22:26:48 UTC