Re: First pass at TTC spec changes

We should also try to talk about TTC test scenarios to make sure we provide
correct information to Khaled. They may be slightly novel as browsers don't
really support TTC today.

On Mon, Jan 26, 2015 at 7:44 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

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