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)
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].

Received on Thursday, 11 September 2014 22:29:57 UTC