- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 2 Jul 2009 15:19:45 -0500
- 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 IE. 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. ~TJ
Received on Thursday, 2 July 2009 20:20:52 UTC