RE: Fonts WG Charter feedback

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]


> However, I just saw your most recent email, and agree that including
> compression would be more difficult than not doing so, but I still
> strongly feel that the benefits are worthwhile here.  Punting to HTTP
> isn't really saving any effort, the way mod_deflate does for us Apache
> users, because you're already having to convert your TTF/OTF fonts
> into the new format (or are receiving the font in webfont format
> directly from the foundry).  Making the actual compression happen on
> the HTTP level just means an additional step of server setup (though
> this can easily become trivial/default) and consumes extra resources
> on the server side that are unnecessary.  Doing all the necessary
> conversions once is a bit simpler for the developer.
HTTP-level compression is fairly commonly used today for large resources. Whether
the extra server-side resources required are 'unnecessary' depends on a host of factors.

First, static resources need not be recompressed every time they are served i.e. that the HTTP response body is gzipped does not mean it *must* be gzipped on demand every time. Given the proper Accept-Encoding header from the  client, any proxy server along the way can serve a gzip file instance in its cache. But even if one did the compression on the fly for each 'fresh' request, the savings in bandwidth and proxy cache space could still be worthwhile for a given site. Bottom line: the overall economics are highly site-specific.

The runtime profile of gzip vs. a font-specific compression scheme may be different but again, I would not expect
this to be a critical factor for long-lived static files.

>
> If your fear is that we prematurely settle on one compression format
> and then later discover a more efficient one, note that compression
> adoption *still* requires browser interop before it can actually be
> deployed.  It would be equivalent to the effort necessary to just
> spawn off a new version of the webfont format with the new compression
> algorithm specified.
That was not my concern. Time to reach agreement and implementation deployment make me lean towards keeping it as simple as possible.

Received on Wednesday, 1 July 2009 21:18:16 UTC