- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Wed, 16 Apr 2014 13:37:54 +0100
- To: Chris Lilley <chris@w3.org>
- CC: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>, Raph Levien <raph@google.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
On 16/4/14 13:04, Chris Lilley wrote: > Hello Jonathan, > > Monday, April 14, 2014, 7:55:54 PM, you wrote: > >> I envisage that before very long, the Brotli compressor is likely to be >> packaged as a reusable library on many systems, so that it would be >> readily available to scripting languages such as Perl or Python or Ruby >> that might be used to build dynamic sites or online tools. I doubt the >> WOFF2 glyf-transformation code is likely to be nearly so widely >> available, given its more specialized nature. > > Doesn't that argument apply to all of the MTX-style preprocessing, > which is all font-specific and all separate from generalized entropy > coding? ISTM that the glyf/loca transformation is the only moderately complex part of implementing WOFF2 (aside from the Brotli entropy coding itself); apart from that, an implementer only needs to deal with the header and table directory, which are pretty simple, and run the concatenation of all the table data through Brotli. 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. Obviously, a dedicated WOFF2-generating tool used by a font foundry to prepare a library of webfonts will want to apply the transform, because it adds value by minimizing the resulting file size. But ad hoc web services that want to generate custom fonts on the fly might view the code-complexity vs font-size tradeoff differently. JK
Received on Wednesday, 16 April 2014 12:38:21 UTC