Re: First pass at TTC spec changes

FYI, I have updated my draft to use 255UInt16 as the index type. DIff here
<https://github.com/rsheeter/woff2-ttc/commit/68f6ed877f61a65d578a21369852fc53cbeb324b>
and
html preview here
<https://rawgit.com/rsheeter/woff2-ttc/master/Overview.html#collection_format>
.

With regard to your questions (in green) from Jan 26th:

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


I had intended that the association was effectively captured in the
CollectionFontEntry's; the glyf/loca pair in the same entry are "paired".
The decoder would have to recognize this; perhaps we need a specific
comment to that effect?

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

Agreed, this is the case and it should be made 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.


Intent was that the decoder can establish the association between pairs
from the CollectionFontEntry data. That is, you parse the table directory
and the collection header+collection font entries and that gives knowledge
of glyf/loca pairings. Perhaps additional verbiage to make this explicit is
called for?

What do you think?


On Wed, Jan 28, 2015 at 6:29 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

>  Yes, we will need to update CTS plans to account for additional TTC
> tests but in order to do it we need to finalize the spec to address
> normative parts and all testable assertions.
>
>
>
> Regards,
>
> Vlad
>
>
>
>
>
> *From:* Roderick Sheeter [mailto:rsheeter@google.com]
> *Sent:* Monday, January 26, 2015 7:33 PM
> *To:* Levantovsky, Vladimir
> *Cc:* WebFonts WG
> *Subject:* 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.
>
>
>