[webkit-dev] EOT Support in WebKit

Maciej Stachowiak mjs at apple.com
Fri Oct 17 18:33:35 PDT 2008


On Oct 17, 2008, at 3:02 PM, David Hyatt wrote:

> On Oct 17, 2008, at 4:58 PM, Peter Kasting wrote:
>
>> On Fri, Oct 17, 2008 at 2:52 PM, David Hyatt <hyatt at apple.com> wrote:
>> 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.
>>
>> Unless we can convince Microsoft to support TTF.  Or other vendors  
>> end up supporting EOT.  Or we write some crazy parser hack that  
>> prefers TTF over EOT when both are available (ugh).
>>
>> It's not clear to me whether "support EOT to make it easier to gain  
>> marketshare in India and thus provide an alternative browser where  
>> authors can deploy TTF" is a better long-term bet for the success  
>> of TTF than "try to convince Microsoft to support TTF in IE".
>>
>
> Microsoft will never support TTF in IE (for HTML at least).   
> Apparently it's ok for Silverlight but not for HTML.
>
> I think it's worth thinking about how to get Web site compatibility  
> in India without supporting EOT.  See some of the discussion in the  
> bug for ideas.

Some of the proposals there sound really interesting.

1) Detect when known unusually-encoded EOT fonts are used, and convert  
text in that font on-the-fly to Unicode. This has the advantage that  
features like "find in page" and copy/paste will work correctly;  
apparently they normally do not when the font is encoded in a way that  
doesn't match the server-stated text encoding.

2) Restrict EOT support to a hardcoded list of fonts and websites, in  
the the cases where we know the compatibility issues are a significant  
adoption barrier.

I think either of these would be better than full-fledged EOT support  
and I would tentatively say that #1 could lead to a better overall  
user experience.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081017/8137934b/attachment.html 


More information about the webkit-dev mailing list