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

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

Received on Wednesday, 4 March 2015 04:32:01 UTC