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 <[EMAIL PROTECTED]>
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev