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> wrote:

>  Hi Rod,
>
>
>
> Please see my comments inline.
>
>
>
> Thanks Vlad
>
>
>
>
>
> *From:* Roderick Sheeter [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> 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.
>
>
>
>
>