RE: eotfast, ttf2eot, mkeot (was: Webfonts from FontFont)

On Tuesday, March 02, 2010 10:23 AM <bert@w3.org>:

Thanks for this, Bert. Being able to make a working EOT "Lite" file - if only for purposes of development and testing - on a variety of platforms can be highly useful.

>*) If the EOT file is served by HTTP, and depending on the configuration
>of the server, you may be able to gzip the file, or maybe the server
>even does it automatically.

Gzip brings additional costs, barriers, and uncertainties that native compression does not. (To me, native compression is *the* main virtue of WOFF. As, of course, it is with formats like GIF, JPEG, and PNG.)

1) The Uncertainties Of Gzip
The list of benefits on the EOTFAST main page says:
"avoid the hit-and-miss of server-side Gzip compression"
Hit and miss pretty much sums it up. Gzip is a bit of a crap-shoot, unfortunately.
If you depend on gzip alone to deliver a font, there is a chance that as many as 10%-15% of your visitors will never get the font, depending upon network conditions.
A chapter titled "Going Beyond Gzipping" (written by Tony Gentilcore) in Steve Souder's book Even Faster Web Sites,  explains in full.
This link will partially explain:
http://www.stevesouders.com/blog/2009/11/11/whos-not-getting-gzip/

This problem has been verified by someone with an especially large amount of experience in serving font files - Garrick Van Buren of the font services site Kernest. He initially tried delivery with gzip but had to roll back because customers were reporting not getting the fonts.
Just recently, though, he wrote about a solution he has found satisfactory, at least for Kernest's purposes:

http://garrickvanburen.com/archive/how-to-make-safari-render-pre-gzipped-web-fonts
http://darrenrush.com/2008/08/caching-and-compression-for-apache-and-mod_rails/

For EOT files however, at Kernest, gzip is icing on the cake: Kernest's library was converted using EOTFAST.

2) Additional Costs and Barriers

To enable gzip, I had to upgrade my yearly hosting plan to one that costs more than twice as much.
In addition to the hosting costs, it puts an additional and substantial load on the server.
Further, for many, the necessary level of technical expertise and/or access to the server at that security level, makes gzip highly problematic if not impossible.

But drag-and-dropping a TTF onto an executable file is a no-brainer.

I'd like to see the barriers to publishing on the web kept as low as possible. Participation on the web defies the traditional dichotomy between "amateur" and "professional". Those folks somewhere in the middle of the spectrum who get along, technically, by the skin of their teeth are always foremost in my mind. The gurus can take care of themselves - and they benefit from the simplest, lowest-cost approach, too.

Perhaps the folks at Typekit - who also have much experience serving font files - could provide useful information about this for the benefit of the community at large.

Thanks again.

Rich
http://readableweb.com



-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Bert Bos
Sent: Tuesday, March 02, 2010 10:23 AM
To: 'www-font'
Subject: eotfast, ttf2eot, mkeot (was: Webfonts from FontFont)

On Monday 01 March 2010 13:48:51 Adam Twardoch (List) wrote:

> As for the comparison between ttf2eot and eotfast.exe, it's fair to
> point out that ttf2eot does not incorporate the patented Monotype
> MicroType eXpress (MTX) compression while eotfast.exe does (as MTX is
> used by Windows). Typically, EOTs created with eotfast.exe will be
> smaller than those created with ttf2eot.

The EOT files from ttf2eot didn't work for me, so I decided to write my 
own converter. My mkeot program writes EOT version 2.2. Unlike ttf2eot, 
it fills in *all* the fields in the EOT header, adds URLs ("root 
strings"), and respects the embedding bits of the original font. Unlike 
WEFT, it doesn't do any subsetting and doesn't compress the font 
data(*). It's written in C and is Open Source:

    http://www.w3.org/Status#eot-utils

There is a companion program eotinfo in the same package to display 
what's in an EOT header.

No binaries for the moment, you need to compile it yourself. Tested on 
Linux and Mac OS X. It uses the non-POSIX err() function from BSD, 
which I could remove if needed, but otherwise it should compile 
anywhere with a standard C compiler.


*) If the EOT file is served by HTTP, and depending on the configuration 
of the server, you may be able to gzip the file, or maybe the server 
even does it automatically.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Tuesday, 2 March 2010 19:12:12 UTC