RE: Webfont compression

According to your own tests with "Georgia":
EOT file size created using (ttf2eot + gzip) is 32.6% larger than EOT
file with MTX compression created by WEFT. Since both gzip and MTX are
lossless compression techniques, I think that 32.6% improvement could be
considered significant. 

MTX employs a two-step process where the font data is first optimized
and then subjected to entropy coding (modified LZCOMP). It is most
effective for a screen font that contains larger glyph sets and
significant amount of hint instructions. Since screen fonts require
hinting and are much more likely to be used on the web, I would consider
an efficient compression an advantage for web fonts. Plus,
MTX-compressed font contains separate blocks of font data, which  makes
it possible to implement a progressive font download mechanism where
metrics and layout information can be used by a UA to layout a web page
while the glyph data and hints are still being downloaded.

Also, it has been shown that there are new compression techniques, such
as LZMA, that produce better results than gzip. It is important to keep
in mind that even though MTX is originally a part of EOT submission -
nothing would prevent W3C and Fonts WG to create a new, truly superior
technology where, for example, parts of MTX (font optimization) can be
combined with LZMA to produce best possible results. This technology
could potentially be part of a future .webfont implementation.

However, having said this - I believe that the major benefit of web font
initiative would be to come up with a solution that can address the
largest number of web users in a shortest time possible; a solution that
would give web authors tools they need today. For this reasons - I think
that a subset of EOT (either EOT with MTX but without root strings, or
EOT-lite) would be most pragmatic way to make web fonts a web reality
today, addressing the large base of IE users.

Regards,
Vladimir


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Laurence Penney
> Sent: Tuesday, July 21, 2009 11:29 AM
> To: www-font
> Subject: Webfont compression
> 
> It seems to me the benefits of Monotype's Microtype Express
> compression are being oversold. Until recently I was under the
> impression that its patented font-specific algorithms performed
> significantly better than normal compression.
> 
> But then I actually ran some tests, comparing WEFT compression and
> gzip compression:
> 
>                     Georgia  Vera Sans Mono
> TTF                 155068           49224
> EOT (ttf2eot[1])    155234           49454
> EOT (WEFT)           73907           24113
> TTF (gzip)           97965           27971
> EOT (ttf2eot+gzip)   98013           28038
> EOT (WEFT+gzip)      73920           24058
> 
> This demonstrates first of all that the zip compression of Tal &
> Erik's .webfont proposal is almost as good as the dedicated MTX
method.
> 
> But more interestingly, gzip compression is built into both browsers
> and Apache[2]. For example, this webfont demo page, hosted at cheap
> shared hosting company, is serving compressed TTF and EOT as well as
> compressed HTML:
> 
> http://www.lorp.org/webfont/
> 
> While HTML is often compressed by default, a single line in Apache
> 'SetOutputFilter DEFLATE' compresses all served files (though of
> course in practice this would be better done on a per-filetype basis).
> 
> (By the way, another Apache line 'RewriteRule ^(.*)\.ttf$ /webfont/
> $1.eot [L]' allows the @font-face CSS in that demo page to be the same
> for IE and non-IE browsers, referring always to .ttf files.)
> 
> For the record, of about a dozen websites I checked using
> GIDZipTest[3], these were the only ones serving uncompressed data:
> 
> www.monotypeimaging.com
> www.ascendercorp.com
> www.w3c.org
> www.tiro.com
> 
> - L
> 
> [1] http://code.google.com/p/ttf2eot/
> [2] http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
> [3] http://www.gidnetwork.com/tools/gzip-test.php
> 
>

Received on Tuesday, 21 July 2009 16:24:07 UTC