Re: Some notes on the WOFF specification

Thanks for this, Chris. Remarks below:

On 20 Oct 2010, at 13:58, Chris Lilley wrote:

> Hello Jonathan,
> 
> Going over the spec to do my actions, I noticed several things:
> 
> a) Working on my actions ACTION-21 ACTION-27 to write a test plan, it would be handy if I could edit the spec to add IDs to each testable assertion and a class attribute to say that its testable and also to say what type of product it would apply to (generator, user agent, woff file). Like this
> 
> <span id="t123" class="testable ua">.... </span>
> 
> Not knowing whether you have pending edits, I'm sending this email ahead of the call and won't make edits until after the call.

Ok, I just pushed a minor edit that was pending; feel free to go ahead after the call.

> 
> b) It looks as if we changed from a convention where all must should may etc are RFC2119, to one where only MUST SHOULD etc in caps are RFC2119 and lowercase have their normal English meaning. The statement on Notational Conventions should be updated.

I updated this in my edit just now. Please see if you think that covers it.

> 
> c) I found a conflicting assertion: 
> 
> User agents MUST likewise assure that the sfnt table directory is recreated in ascending tag order when restoring the font data to its uncompressed state
> 
> and
> 
> User agents MAY reorder tables when decoding the WOFF file to sfnt form, but should be aware that this means the resulting sfnt will no longer be an exact copy of the original, and checksums or digital signature data may be invalidated as a result. (Note that user agents need not necessarily reconstitute the original sfnt as a whole; they may access individual tables directly as needed.)

I don't believe these are in conflict: the first is about the order of table DIRECTORY entries, which are required to be sorted (so that clients can binary-search for specific tables), the second is about the order of the actual tables within the file.

> 
> I have a way to resolve this, which would also firm up 
> 
> the overall font checksum of a font decompressed from a conformant WOFF file should always match the checksum in the original, valid sfnt-based font file, except in the case where the original file included unreferenced data between or after the actual tables;
> 
> and also deal with generators that directly create WOFF without first creating an sfnt font.
> 
> d) I have another action, ACTION-24 to talk with you about the citation style and layout of the references section. Basically to split it into normative and informative references per
> http://www.w3.org/2001/06/manual/#References
> We should work out some time, perhaps this week, to discuss this.

Yes, I'm aware that is pending but haven't given any thought to it. Would some time tomorrow work for you?

Jonathan

Received on Wednesday, 20 October 2010 14:16:12 UTC