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 14:35:21 -0500
Message-ID: <dd0fbad0907021235s59e1bf25xaf477f9961351c10@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Mikko Rantalainen <mikko.rantalainen@peda.net>, www-font <www-font@w3.org>
On Thu, Jul 2, 2009 at 1:55 PM, Aryeh Gregor<Simetrical+w3c@gmail.com> wrote:
> On Thu, Jul 2, 2009 at 9:55 AM, Mikko
> Rantalainen<mikko.rantalainen@peda.net> wrote:
>> 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 don't think (3) is necessary.  Let's say EOT Lite specified that all
> browsers had to implement same-origin restrictions, and
> Firefox/Safari/Chrome/Opera implement it like that in their first go.
> IE, however, doesn't have same-origin restrictions before IE9 at
> least.
>
> If someone hotlinked your font, it would work . . . but only for IE
> users.  This would probably result in complaints to the hotlinker from
> his users, especially if IE's market share continues to decline.  It
> would be possible to do, but it's unlikely to happen much, since it
> will fail for a lot of users.
>
> So this proposal would have a significant degree of same-origin
> restriction even if old IE didn't do it.  Of course it's confusing to
> have some browsers implement same-origin restrictions and some not --
> but that's already the status quo with OTF/TTF.
>
> So define EOT Lite as being the same as the EOT spec published by
> Microsoft, but the root string must be null; MTX and xor obfuscation
> must be disabled; same-origin restrictions are mandatory; some marker
> is added that won't stop old IE versions from using it, but will allow
> future ones to recognize it and implement the origin restrictions
> without affecting old EOT; and a new extension is used, like .eol or
> .otw.
>
> This is functionally very similar to Ascender's proposal.  The only
> important differences I can see are 1) old IE versions will render it
> cross-origin, but 2) it will work in old IE versions (huge benefit!),
> and 3) Microsoft's cooperation is not essential for it to be useful
> (which might allow more rapid deployment, since the disputes that have
> been holding us up are mostly MS vs. everyone else).  I think (2) and
> (3) *far* outweigh any problem with (1).
>
> (Yes, it will have some silly checksums and so on.  But that doesn't
> make implementation much harder and it's invisible to users, so it's
> not a big deal.)
>
>> One can copy an EOT Lite font file from
>> a remote server to his own server and it would work just fine.
>
> The same is true for Ascender's (original) proposal.

Without rootstrings (but *with* same-origin restrictions, modulated
through CORS), I can accept using EOT in my workflow.  I'd like a
processing tool that's a touch more friendly than WEFT, but I can live
with it.

~TJ
Received on Thursday, 2 July 2009 19:36:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:02 GMT