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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
