RE: Fonts WG Charter feedback

On Wednesday, July 01, 2009 6:45 PM Jonathan Kew wrote:
> 
> On 1 Jul 2009, at 21:56, Tab Atkins Jr. wrote:
> 
> > I don't see any good reason to make compression optional in a new
> > webfont format.  Using existing uncompressed TTF/OTF has benefits
(no
> > effort at all, and already works in most major UAs), but if we're
> > going to the effort of defining a new standard webfont format as
> > well, we might as well make it truly worth it.
> 
> Yes, this is my view as well. I believe useful compression can be
> included without significantly greater effort for implementers
> (slightly greater, yes, but not enough to present a hindrance to
> adoption), and of course with no additional burden at all for users,
> and will provide long-term benefits in real-world usage.
> 

I share both of your views on this. I think that compression is going to
be the most valuable component of the new web font format, providing
benefits for both authors and users.

> And of course, if compression is a standard part of the format (rather
> than optional), there is no longer any need for table-name
obfuscation.
> 

Agree.

> > It's been shown that
> > standard gzip is significantly less efficient than certain other
> > methods,
> 
> Agreed. Personally, I think the stability and ease of implementation
> that gzip offers outweigh this; if vendors can support the format with
> a few dozen (ok, maybe a few hundred) lines of code wrapped around
> calls to zlib, this is a considerably lower barrier to adoption than
> adding a dependency on lzmalib (whose license would, I think, prevent
> some browsers using it) or the LZMA SDK (a lower-level and more
> complex interface, as I understand it), or including a considerable
> amount of new code to support MTX.

FWIW, the complexity of MTX  is mostly on the compressor side that takes
care of all font-specific optimizations. The decompressor itself has
just a bit more code than generic decompressor has.

Vladimir

Received on Thursday, 2 July 2009 01:08:41 UTC