RE: Action 138 "Table directory" (was RE: Telcon minutes, Wednesday, Sep. 10)

Both SFNT and WOFF 1.0 have the table directory entries sorted in alphabetical order which is *not* the case with WOFF2.

Looking at the "Table Directory" spec - there is no mentioning there that the table order is different from the original font and specifies the exact order in which the table s appear in the compressed font stream (we do mention it in passing in the compressed font format section). Should we make it explicit and define it here as well to make sure that there is no ambiguity?

Thank you,
Vlad


From: Levantovsky, Vladimir
Sent: Thursday, September 11, 2014 6:29 PM
To: Levantovsky, Vladimir; w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: Action 138 "Table directory" (was RE: Telcon minutes, Wednesday, Sep. 10)

Folks,

Some thoughts that I want to run by you:

1)      As we discussed during the call - adding any padding requirements to table directory entries would probably be silly. Each entry has one byte of flags followed (in the majority of cases) by a single, variable length UIntBase128 value. All known table tags will not be there (at least those that we know of today) and only two tables will have an extra field when the transformed length UIntBase128 value is present. So, for the majority of cases each table entry would likely be 2-5 bytes long, and require 4-byte alignment and padding of up to 3 extra bytes would eat away any and all benefits of using variable-length encoding for table length.

2)      If the above is true, than there is no way to know ahead of time where one entry ends and another one begins - we only know the number of entries so a decoder has to process everything sequentially to figure out where the table directory ends and a compressed font stream begins. The compressed font stream does begin on 4-byte boundary and does require padding (as we agreed yesterday) but it is the only one among the compressed data streams where its initial starting position in the file is not apriori known (one need to process the table directory to figure that out).

Would it be useful and/or make sense to have a field defined that would allow a decoder to start reading the compressed font stream immediately, before the table directory is parsed? If so, the reserved field (which I am not sure why we needed it other than for data alignment issues) could be used to signal the size of the table directory in bytes. I realize that Uint16 isn't much but for table directory that is likely to never have more than double-digit number of entries up to 11 bytes long (in the worst case) - UInt16 would be more than sufficient.

Comments?

Thank you,
Vlad


From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com]
Sent: Wednesday, September 10, 2014 5:14 PM
To: w3c-webfonts-wg (public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>)
Subject: Telcon minutes, Wednesday, Sep. 10


      [5] http://lists.w3.org/Archives/Public/public-webfonts-wg/2014Aug/0013.html

   Vlad: should all table directory conformance statements carry
   forward? Would be a good ideal to review, wouldn't want to
   automatically carry everything forward
   ... esp. as there are some that do not apply (e.g. padding
   between tables)

   <scribe> ACTION: vlad review conformance statements for WOFF
   1.0 and transfer the applicable ones over [recorded in
   [6]http://www.w3.org/2014/09/10-webfonts-minutes.html#action01]

   <trackbot> Created ACTION-138 - Review conformance statements
   for woff 1.0 and transfer the applicable ones over [on Vladimir
   Levantovsky - due 2014-09-17].