W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: A way forward

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 23 Jul 2009 16:02:02 -0700 (PDT)
To: www-font <www-font@w3.org>
Message-ID: <10900862.31591248390122845.JavaMail.root@cm-mail02.mozilla.org>
Right now linking to TTF/OTF fonts represents what will soon be an
interoperable solution for all browsers other than Internet Explorer.
Some authors may consider this to be enough, using @font-face only as
a progressive enhancement for their sites.  For a more interoperable
solution, authors can also choose to serve EOT versions of fonts to
Internet Explorer users.

As I understand it EOT-Lite boils down to a header prepended to the
front of a font, with no MTX data compression and a null root string.
I'm assuming the silly XOR'ing of the data (TTEMBED_XORENCRYPTDATA)
has been omitted.  None of the remaining data in that header seems
like it's useful, the data is either already in the font or it's
defined in the @font-face rule.  You might as well just prepend a null
four bytes to the font data, that would have the equivalent level of
protection, you wouldn't be able to use the font file as a desktop

If Microsoft can ship an update to support CFF fonts in an EOT format
in older browsers on older operating systems they certainly could ship
an update to support a simple format like this, I don't see a why
other browser vendors should bend over backwards because Internet
Explorer has long product cycles.

Either the .webfont format or Jonathan Kew's ZOT format seem fine to
me, but I think Mozilla would only support an additional format that
other browser vendors were also willing to support, including
Microsoft.  And I don't see any other browser vendor eager to support
any variant of EOT (with or without the spicy mustard) other than

John Daggett
Mozilla Japan
Received on Thursday, 23 July 2009 23:02:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:32 UTC