RE: Open issues in the WOFF 2 draft spec

FWIW, I can easily imagine that Brotli would become a standard library, but just because it is easy to implement one particular part of the spec I don't see why we should make it easy to disregard all other parts. In essence, it is like saying that we worked long and hard to make the best possible web font compression technology (and we've proven that it has a significant value) but we invite you to ignore it! Why is it good?

Glyph transform (and everything else that constitutes the pre-processing step) can easily be implemented in any language (in fact, a significant chunk of our own in-house font production tools are written in Python) and I just don't see a compelling reason or a use case where an optional path to  go around pre-processing step [that significantly reduces font data size] is justified. A code to do it needs to be written only once, the benefits will be realized by millions of users - why we should make it easy to not write the code?

Thank you,
Vlad


On Wednesday, April 16, 2014 8:38 AM Jonathan Kew wrote:

So my impression is that if Brotli becomes available as a standard library (which I expect will happen) it will be considerably simpler for someone to generate WOFF2-encoded font data from any arbitrary language (Perl, Python, Ruby, Lua, PHP, Javascript, whatever....) if they're allowed to skip the glyf-table transformation. I think that's an attractive option.

Received on Wednesday, 16 April 2014 13:56:58 UTC