[webkit-dev] EOT Support in WebKit

David Hyatt hyatt at apple.com
Fri Oct 17 14:52:31 PDT 2008


On Oct 17, 2008, at 2:22 PM, Amanda Walker wrote:

> On Fri, Oct 17, 2008 at 12:41 PM, David Hyatt <hyatt at apple.com> wrote:
>> The big problem is if you support it, EOT wins.  We may as well  
>> remove
>> the TTF code path from the tree.  EOT is unwieldy to use, doesn't
>> support the full range of TTF, contains URL restrictions that make it
>> cumbersome to stage (access control could work much better).
>
> I'm not sure I follow the "we might as well remove TTF" reasoning,
> especially in light of the usability problems you mention.
>
> Putting on my Amateur Web Developer hat, TTF support is something I've
> been avidly awaited for many many years.  I mean, I'm a font geek, and
> have been trying every downloadable font technology anyone's created,
> from TrueDoc to SIFR.  @font-face with TTF is the only reasonable one
> out there--doesn't take proprietary (and pricey) tools, or a Windows
> box, or whatever.  Just host the font file and write some CSS.
>
> 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:

@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.

Now it may be the case that IE properly skips TTF files and moves to  
the next file in the list (but I don't think it does).

It's important to recognize that if you flip the EOT switch, you're  
going to end up using EOT over TTF in many cases.  In fact if IE  
*does* in end up skipping TTF files properly, the font you get in  
Chrome would actually depend on the specification order in the @font- 
face rule (you'd just end up randomly using EOT sometimes and TTF  
other times).  You'd be the only vendor subject to this issue by  
supporting both formats.

>> Ok, fair enough.  It would be good to get an official position from
>> Google on this (maybe even on www-style).  Right now the message I'm
>> getting from Google folks is very muddled.
>
> Putting my Google hat back on, I will say that I will strenuously
> argue *for* including TTF downloadable fonts.  I have no strong
> opinion about supporting EOT without DRM, and will argue against
> supporting EOT with DRM. But that's speaking as an individual
> engineer--we haven't really talked it over as a team yet (the proposed
> patch came out of the blue to use as much as it did to anyone else).

I'm very concerned about deliberately ignoring DRM specified in the  
EOT format.  The browser vendor could be blamed for ignoring the DRM.   
That is not the case with a format like TTF.

dave



More information about the webkit-dev mailing list