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

Re: EOT Lite - possible outcomes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 Jul 2009 15:19:45 -0500
Message-ID: <dd0fbad0907021319r4cab8773o283d2adb50f2dce5@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Mikko Rantalainen <mikko.rantalainen@peda.net>, www-font <www-font@w3.org>
On Thu, Jul 2, 2009 at 2:51 PM, Levantovsky,
Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> On Thursday, July 02, 2009 9:55 AM Mikko Rantalainen wrote:
>> Levantovsky, Vladimir wrote:
>> > EOT version 1.0 doesn’t even have a place for root string to be
>> > inserted. I’d assume that the only difference between EOT 1.0 and EOT
>> > Lite would be compression (which is optional for authors to use but
>> is
>> > required for UA to support). I guess EOT Lite just removes that
>> > option.
>> I want to make sure we're on the same map here. Do you think that
>> Monotype and other commercial font vendors would be happy with EOT Lite
>> given the following status:
>> (1) EOT Lite font files do not include rootstrings
>> (2) EOT Lite font files do not include compression
>> (3) EOT Lite font files do not require same-origin restrictions
>> Note that (1) and (2) are required so that Firefox, Safari and Opera
>> can implement EOT Lite. The (3) is required for MSIE compatibility, so
>> we have no choices here.
> I think I can live without root strings if another mechanism for access control (CORS) is present. Older IE versions will not support it but new browser versions (Safari, Firefox and others, including IE9) would, and this would be sufficient. On point (2), I can live without it but I truly believe that compression is useful and needed, and it would be a mistake not to do it - with MTX offered with unrestricted license any browser can implement it.

While I also believe that a compressed format would be ideal looking
forward, an EOT-based proposal has some significant benefits, at least
as another interim format.  We can still deploy server-based
compression on the fly, as we currently do with gzipping.  In a
previous exchange with Sylvain I said that I preferred the compression
to be on the file itself, as it would be simpler, but setting up
compression with an Apache module like mod_deflate is only slightly
less trivial.  An advantage of doing that is that the UA can tell the
server that it's able to accept compressed fonts (just as today UAs
tell servers that they can accept gzipped resources), allowing you to
put a single uncompressed EOT-ish file on your server and
automatically serve it up plain or compressed as necessary.

Simply put, I would *really* like to start using fonts with a single
file in the immediate future, rather than 5-7 years from now
(optimistically).  Without any intended malice, IE users are by far
the slowest tech adopters, so *anything* new that we produce will have
its useful adoption time held up by IE users for far longer than the
users of any other browser.  Nothing the IE team (or anyone else) can
do will change this fundamental fact - the average person on the web
simply isn't technologically sophisticated, and so they use the
default browser presented to them, which for the majority of people is

If we can find a way to get IE6 and/or 7 on board that is palatable to
authors, the other browsers, and font foundries, we have a magic
bullet for at least an interim format.  We can then talk about future
formats without worrying that we're holding up the adoption of
webfonts as a whole.  It sort of sounds like an EOT Lite that is
without root strings or compression, and without same-origin
protections in older IEs (but *with* such protection in newer
browsers) would work.

Received on Thursday, 2 July 2009 20:20:52 UTC

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