[webkit-dev] EOT Support in WebKit

[David Storey]

On 18 Oct 2008, at 03:33, Maciej Stachowiak wrote:

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

Just to add the Opera 2 cents into this, we have evangelism activities  
going on around compatibility.  We've known about the EOT issue in  
India for a long time now.  We have had and continue to have success  
in convincing Indian sites to move away from EOT to more open  
equivalents  like switching to UTF-8 encoded content.  IMHO hard work  
and good evangelism works out over bending over backwards supporting  
EOT.

Couple of quote from our guys:

> This was a problem with a large number of Hindi websites when I  
> checked
> last year but it does not seem to be a problem today. I checked a
> directory of Hindi websites http://dir.hinkhoj.com/ and most of them  
> don't
> use EOT any longer. The only major news site using EOT on the list  
> right
> now is http://www.amarujala.com/today/default.asp
>
> But I've only checked Hindi websites not sure about other regional
> languages in India.

and

> Yes, Indian regional sites, especially news sites and religious  
> sites, do
> use EOT.
> I've contacted some of them, and a many of those have now recently
> changed and switched to UTF, but still a quite a few regional sites  
> remain
> which still use EOT.
>
> Just a quick example, amarujala.com, eenadu.net, iift.edu/hindisite/ ,

So, yes there is still work to be done, but it is clear that if there  
is benefit for the sites to change, i.e., only IE supports EOT and  
changing allows Opera/Safari/FF/Chrome to work, then they will change.  
I‘m very willing to discuss with the Safari and Chrome people on how  
we can work together to solve such issues in a optimal way, and pool  
our evangelism resources.



>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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