RE: First pass at TTC spec changes

Yes, the mismatch in glyf/loca association and what is called for as part of the CollectionFontEntry is something we would have to watch for, but at the same time it may actually be a benefit since it gives us the opportunity to catch the erroneous content before it screws up the font rendering side of the business.

Vlad


From: Roderick Sheeter [mailto:rsheeter@google.com]
Sent: Tuesday, February 03, 2015 6:07 PM
To: Levantovsky, Vladimir
Cc: WebFonts WG
Subject: Re: First pass at TTC spec changes

The downside I see is that it becomes possible to express an inconsistent association if we depend on the ordering. That is, I could write out a table directory that said glyf1 goes with loca1 and then in my collection font entry say font1 uses glyf1, loca2. As long as we call this type of inconsistency out as decoder MUST reject (and thus have a test for it) then glyf always followed by associated loca seems fine to me.

If there are no objections tomorrow, I will undertake to update my draft of the TTC changes to match for next weeks call.

On Tue, Feb 3, 2015 at 2:39 PM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto:Vladimir.Levantovsky@monotype.com>> wrote:
Hi Rod,

Please see my comments inline.

Thanks Vlad


From: Roderick Sheeter [mailto:rsheeter@google.com<mailto:rsheeter@google.com>]
Sent: Wednesday, January 28, 2015 5:19 PM
To: Levantovsky, Vladimir
Cc: WebFonts WG
Subject: 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?

<snip/>

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

It is definitely a possibility but it also means that the decoder should parse the CollectionFontEntry table twice – first before applying the post-processing on the glyf and loca tables to figure out which ones are associated with each other, and the second time when the actual fonts are built as part of the font collection. I’d rather eliminate the need for extra parsing by e.g. asking the encoder to reorder the tables in the input stream so that each ‘glyf’ table must be followed by  the ‘loca’ table that is associated with it – this way you can process all tables in a single pass and then parse the CollectionFontEntry table to while rebuilding each font entry at the same time.

My personal preference (FWIW) would be to always ask the encoder (running on a server) do more and have the decoder (running on a device with varying degrees of memory limitations and CPU power) streamlined as much as possible.


On Wed, Jan 28, 2015 at 6:29 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto: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<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<mailto: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<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.