RE: First pass at TTC spec changes

Hi Rod, all

Rod, thank you for taking a good chunk of your Pacific time to work on the TTC proposal. It looks good, I like the proposed structure and but I do have some comments that we can discuss at the upcoming telcon.

1)      Data type for table directory indices.

The majority of existing fonts have much fewer than 253 tables, so using 255UInt16 instead of UInt16 here will almost guarantee to save us 50% of byte count needed to encode the table indices of a font collection entry. Considering that the number of bytes saved would be (N_fonts *N_table_entries) this could add up to something meaningful amount and since the 255UInt16 is already defined and used elsewhere we will get these savings for free.

2)      Sharing of ‘glyf’/’loca’ tables.

I think we may need to re-word the last paragraph and dedicate some time and spec real estate to clearly explain that ‘loca’ and ‘glyf’ tables are intimately related at the data structure level and that while using both of them as shared tables in font collection entries is perfectly fine (and is encouraged) multiple pairs may be present. Likewise, if more than one pair of glyf/loca tables is present in a font collection, some of the pairs may be shared among TTC entries but can only be shared as a pair.

However, this begs the answer to the following questions:

-          when the encoder sees multiple entries of the ‘glyf’ & ‘loca’ tables in the TTC file – what, if anything, needs to be done to preserve the association between a pair of tables? The TTC font offset tables will point to only one of ‘glyf’ and one of ‘loca’ tables but the physical tables can be encoded in an arbitrary order (e.g. we may see a random sequence of ‘loca1, loca2, loca3’ followed by ‘glyf1, glyf2’, glyf3’). While offsets are explicit and using them to point to a specific table location within a file is fine, the use of indices to a table directory entry in woff2 file can be tricky because the decoder needs to know which of the ‘loca’ tables was associated with which ‘glyf’ to regenerate them in proper sequence.

-          The encoder can figure out dependencies between multiple glyf/loca tables by parsing TTC offset tables. Should we mandate this? (I think the answer is “yes”, and is implicit in the requirement to generate a valid CollectionFontEntry but we should probably say it in the spec and make it explicit.)

-          Should we also require that the table directory order generated by the encoder should always contain glyf/loca tables as the associated pair, or should we somehow indicate which two of them are associated with each other? The original file can have tables written in arbitrary order and the use of offsets makes it a no-brainer to render a TTC font entry, but since the WOFF2 decoder must regenerate ‘loca’ tables on the fly it *needs* to know which tables belong to each other, otherwise using the indices to point to table directory entries will result in a nightmare.

Hopefully, we will have enough time and a number of able participants to sort through these questions at the next telcon. ;-)

Cheers,
Vlad



From: Roderick Sheeter [mailto:rsheeter@google.com]
Sent: Tuesday, January 20, 2015 9:17 PM
To: WebFonts WG
Subject: First pass at TTC spec changes

Good Pacific-time evening,

I have taken a pass at TTC spec changes. Updated HTML can be viewed @ https://rawgit.com/rsheeter/woff2-ttc/master/Overview.html#collection_format or by cloning https://github.com/rsheeter/woff2-ttc.


The key diff is https://github.com/rsheeter/woff2-ttc/commit/9059b92f673bef0b0276c8d8e9dd49ce2d7b93f4


Comments and suggestions would be most appreciated.

Thanks, Rod S.