[webkit-dev] EOT Support in WebKit

[David Hyatt]

On Oct 17, 2008, at 5:03 PM, Amanda Walker wrote:

> On Fri, Oct 17, 2008 at 5:52 PM, David Hyatt <hyatt at apple.com> wrote:
>> On Oct 17, 2008, at 2:22 PM, Amanda Walker wrote:
>>> EOT is irrelevant to the technical and operational advantages of  
>>> TTF.
>>>
>>
>> That's simply not true.  In order to avoid using multiple browser- 
>> specific
>> stylesheets, vendors are going to write code like so:
>
> OK, I must not have phrased myself well.  There's a set of web
> developers who will use TTF but will not use EOT (just as they have
> not so far, did not use TrueDoc, etc.).  Removing TTF support would be
> a disservice to that set of users regardless of whether or not EOT is
> also supported.
>
>>
>> @font-face {
>>       font-family: MyFont;
>>       src: url(font-for-ie-and-chrome.eot),
>> url(font-for-firefox-and-safari.ttf);
>> }
>>
>> They will take advantage of the fact that WebKit and Firefox can  
>> skip EOT
>> files in the src declaration list.
>
> Why would someone prefer an EOT version to a TTF version if they are
> serving both?  If they are relying on DRM, this removes any advantage
> of it, since they are serving a non-DRM alternative.

EOT would be served by the Web site in order to be IE-compatible.  If  
EOT is listed first and you support it, then you have to use it.  You  
can't prefer TTF if it's #2 in the list, since that violates the @font- 
face specification, which states that the order the fonts are listed  
is the order that they have to be used.

My point is really just that there is a font format war with two  
sides: the EOT side and the TTF side.  Neither side is going to yield  
to the other.  If you try to work with both formats, you're going to  
end up sometimes using the IE code path and sometimes using the FFX/ 
Opera/Safari code path.

dave
(hyatt at apple.com)