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

My understanding is that Chrome currently takes the font and throws it
directly - in woff2 or woff or whatever - to OTS and gets back a "safe"
font, ready to use.

I believe Firefox does something similar although I'm not sure whether it
sends OTS the woff2 or decompresses first.

As such, fails OTS == does not work in browser for the most part.
On 3 Mar 2015 8:32 pm, "Levantovsky, Vladimir" <
Vladimir.Levantovsky@monotype.com> wrote:

>  I am still puzzled by the role OTS plays in all this. WOFF2 encoder
> takes the input TTF/OTF font and reorders/transforms/compresses the tables
> packaging data into a single stream. The decoder is supposed to
> decompress/restore/reorder tables and package them back into TTF/OTF
> format. Where in this sequence of events does OTS play a role?
>
>
>
> Thank you,
>
> Vlad
>
>
>
>
>
> *From:* Roderick Sheeter [mailto:rsheeter@google.com]
> *Sent:* Tuesday, March 03, 2015 11:24 PM
> *To:* Levantovsky, Vladimir
> *Cc:* WebFonts WG
> *Subject:* 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?
>
>
>
>
>