Re: EOT and EOT-based proposals

On 3 Jul 2009, at 07:36, Patrick Garies wrote:

> Tab Atkins Jr. wrote:
>> So, let's talk details.
>
> It seems that the positions are:
> Microsoft: No OTF/TTF; Yes EOT or "EOT Lite"
> Mozilla: Yes OTF/TTF; No EOT or "EOT Lite"
> Apple/WebKit: Yes OTF/TTF(; No EOT or "EOT Lite"?)
> Opera: Yes OTF/TTF(; No EOT or "EOT Lite"?)
>
> So we have three vendors in favor of OTF/TTF with Mozilla, at least,  
> insisting that it be available. We have Microsoft having the  
> opposite position that OTF/TTF should *not* be available on the Web  
> while supporting their existing format, EOT or an EOT-compatible  
> derivative.
>
> If Mozilla, Apple, and Opera implement EOT, that essentially kills  
> OTF/TTF on the Web since Microsoft will have no incentive or  
> interest to implement it. On the other hand, if Microsoft implements  
> OTF/TTF, that will effectively kill EOT for the same reasons.
>
> That seems to kill any chance of EOT being implemented elsewhere; I  
> don't see how you can reconcile those positions without other  
> vendors giving in to Microsoft (and saying RIP to OTF/TTF) or  
> Microsoft giving in to the other vendors (where they might be able  
> to get a concession for OTF/TTF/EOT).
>
> The only other compromise left seems to be to create a new format  
> and have all the vendors agree to that, but I've seen very little  
> discussion on OTW or other new formats essentially meaning that this  
> group has made pretty much no progress so far.

This seems like a pretty fair picture of the current situation, which  
is why I'd love to hear a few more direct answers to the question I  
posted yesterday.


> Mozilla has stated the most willingness to implement another format,  
> it looks like, but that's kind of useless without commitment from  
> Microsoft since Microsoft is the party central to the issue here.
>
> Tab Atkins Jr. wrote:
>> First, are there any legal issues preventing any of the other
>> browsers (particularly Firefox with its GPL obligations) from
>> implementing EOT? I don't believe there is any, but I want to make
>> absolutely sure.
>
> I believe someone mentioned wanting to see the patent license while  
> the patent holder refuses to incur expenses for writing such a  
> license until someone commits to implementing EOT. So, presumably,  
> that depends on what the as-of-yet unwritten license says.

While it would of course be nice to see an actual license, Monotype  
(Vladimir) has given us a very explicit assurance that I think we can  
assume is given in good faith.

>
> Tab Atkins Jr. wrote:
>> Third, can we add same-origin restrictions to EOT?  These obviously
>> wouldn't do anything with legacy IE versions, but it *would* be
>> interoperable with all new versions of all browsers.
>
> Doesn't this create another one of those situations where the  
> browser that ignores the standard renders things "better" resulting  
> in the non-compliant browser gaining more market share (and hence  
> why certain vendors have refused to implement certain standards)?  
> This is more interesting considering Microsoft's Compatibility View,  
> which, presumably, would render the page without these restrictions  
> (and, thus, "better") even if Microsoft committed to implementing it  
> in a later version.

I think this is a serious concern. Promoting "no-rootstring EOT" as  
the recommended web font format (which means that tools to create  
rootless EOT fonts become widespread) will inevitably (IMO) lead to a  
substantial number of sites that misuse such fonts, whether through a  
deliberate choice to infringe (on someone else's license and/or  
bandwidth) or through sheer ignorance. Major sites that test across  
multiple browsers will of course realize the problem and have  
incentive to fix it, but there will be vast numbers of small sites --  
in-house sites, personal blogs, niche businesses being run without any  
real IT support, etc, etc -- that get it wrong, and yet their pages  
work in their existing version of IE.

This matters because it means that such users/markets will find that  
upgrading their browsers (whether to a new version of IE that includes  
same-origin restrictions, or to a different browser) "breaks" web font  
rendering for some sites. This is not good for the overall health of  
the web -- we should not be creating situations where old browsers  
that do not support current standards give users a "better"  
experience. If anything, this will further hold back progress in areas  
where people are already slow to adopt new standards and tools.

I cannot speak for font vendors, of course, but trying to look at  
things from their point of view, I suspect they might be hesitant to  
license fonts for rootless EOT use, even though they would be willing  
to license them for use in a new format that is deployed with same- 
origin controls. The difference, of course, is that rootless EOT fonts  
would immediately be usable through uncontrolled cross-site linking in  
the majority of users' browsers. This seems like a recipe for  
widespread misuse.

AFAICS, a solution that is backward-compatible with existing deployed  
versions of IE must suffer this (fatal?) flaw, unless that solution is  
in fact EOT *with* rootstrings -- which is clearly unacceptable to  
many others.

So to sum up, rootless EOT would:
* create an environment for sites that "work" with IE but degrade in  
other browsers (or a new IE version)
* encourage users to stay with their old IE version, for "compatibility"
* fail to address font vendors' concerns adequately, as the "fence" is  
invisible to a majority of users

Whereas a different format would:
* work with new, compliant browsers, and motivate authors to use fonts  
correctly
* encourage users to update in order to gain compatibility with more  
web fonts
* provide the "garden fence" that vendors have requested

JK

Received on Friday, 3 July 2009 10:11:19 UTC