[webkit-dev] EOT Support in WebKit

Wed Oct 22 09:39:54 PDT 2008

I'm not sure if this has been discussed, but to add a bit more to  
this, the reason why Indian sites were using EOT, and Netscape’s  
equivalent, wasn't so much that they wanted to use a specific font,  
but because at the time of development Uniicode wasn't supported well  
on Windows (Pre-NT) and so many characters couldn't be displayed  
well.  They solved this by using EOT and the likes.  Now that Windows  
supports Unicode, it is only really a legacy issue, except for those  
users using pre-XP OS.  Because of this, sites are more willing to  
just use UTF these days, if we tell them about the compatibility  
issues with EOT and none-IE browsers.

On 22 Oct 2008, at 08:01, Balaji wrote:

> As I understand Tamil is a south Indian Language which is one of the  
> Indian languages that has got highest Internet penetration (It is  
> also an official language in Sri Lanka) nd Singapre). Most of the  
> popular websites in Tamil are already in Unicode. I have been  
> observing that the newer sites are coming only in Unicode and the  
> older ones are moving towards Unicode.
>
> 1. www.vikatan.com
> 2. http://www.kumudam.com/
> 3. www.dinamalar.com (news paper)
> 4. www.thinnai.com
> 5. http://tamil.sify.com/
> 6. http://tamil.webdunia.com/
>
> Some of the popular sites that are still not in Unicode are:
> 1. www.dinakaran.com
> 2. www.dailythanthi.com
>
> From: webkit-dev-bounces at lists.webkit.org [mailto:webkit-dev-bounces at lists.webkit.org 
> ] On Behalf Of David Storey
> Sent: Tuesday, October 21, 2008 5:46 PM
> To: Maciej Stachowiak
> Cc: WebKit Development
> Subject: Re: [webkit-dev] EOT Support in WebKit
>
>
> 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
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081022/ee49a23b/attachment.html>