RE: Pairing glyf/loca causes fonts to fail OTS and thus be rejected by Chrome

Interesting. Reference has not matched spec for a while if the intent was
loca follow immediately after glyf even before ttc.

The reference implementation code predates me, but I would venture to guess
that "*The loca table MUST follow the glyf table in the table directory*"
was interpreted as being met even if there were other tables in between.
So, the encoder would just sort the tables (otspec style) and thus loca
would always "follow" glyf (since previously there would never be >1 of
each), although not necessarily immediately after. The TTC update changed
the reference to put loca immediately after glyf (for both collections and
individuals), and thus caused OTS to be unhappy where it previously was not.

If the tables are not sorted in a WOFF2 then OTS (until very recently at
least) rejects them and thus so will browsers that use it. That is, a table
directory (in a woff2) ordered similar to (glyf, loca, hmtx) rejects but
(glyf,hmtx,loca) does not. This may differ from the spec but it appears to
be the reality on the ground and the end result is fonts that don't work in
browser if the woff2 directory order has loca immediately after glyf.

The upshot of all this is that if we could define the spec such that
encoding the woff2 table directory in otspec order for non-collections is
OK it would make life simpler.

Clear as mud? :D
On 3 Mar 2015 6:56 pm, "Levantovsky, Vladimir" <
Vladimir.Levantovsky@monotype.com> wrote:

>  Hi Rod, all,
>
>
>
> I am not really sure I understand the problem in details yet, but as far
> as the wire format is concerned – we didn’t really change anything. The
> requirement for ‘loca’ table to follow the glyf table in WOFF2 table
> directory has been in place from the early days of the WOFF2 draft and is
> captured in subclause 5.4 as file format conformance case:
> http://dev.w3.org/webfonts/WOFF2/spec/#table_order.
>
> Essentially, we just reiterated the same exact requirement when we added
> the Collection directory format, with the only difference that if you have
> more than one glyf/loca pair they should be ordered as pairs.
>
>
>
> This is nothing new as far as WOFF2 wire format is concerned and, like I
> said, I don’t understand what exactly is different now compared to what it
> used to be. WOFF2 table directory shouldn’t be ever visible to OTS that
> deals with the decoded font where table directory entries should be ordered
> by alphabetical tag order.
>
>
>
> Am I missing something here? Let’s discuss this tomorrow during the
> telcon. BTW, I am just about to upload a new spec version with the media
> type stuff added, stay tuned for the updates and the agenda for tomorrow
> call.
>
>
>
> Thank you,
>
> Vlad
>
>
>
>
>
> *From:* Roderick Sheeter [mailto:rsheeter@google.com]
> *Sent:* Tuesday, March 03, 2015 8:33 PM
> *To:* WebFonts WG
> *Subject:* Pairing glyf/loca causes fonts to fail OTS and thus be
> rejected by Chrome
>
>
>
> I think I have hit a problem with the glyf/loca pairing (implemented in
> woff2 HEAD). Currently HEAD pairs glyf/loca in the woff2 file and re-orders
> (to otspec order) when decoding.
>
>
>
> The latest OTS re-orders tables and accepts this just fine. However,
> legacy OTS (including version in browser) reject a woff2 encoded in the new
> ordering (ERROR: table directory not correctly ordered).
>
>
>
> As a result, if you encode a woff2 using https://github.com/google/woff2
> at HEAD it will not render in Chrome. I think this means the ordering
> effectively represents a breaking wire format change.
>
>
>
> Perhaps we should make the glyf/loca pairing requirement only for
> collections and say regular woff2 table directories should order in the
> otspec recommended order? Other ideas?
>
>
>
>
>