W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

RE: EOT-Lite clarification

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 28 Jul 2009 14:50:38 +0000
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E0210E213@TK5EX14MBXC120.redmond.corp.microsoft.com>

>Can legacy IE implementations deal with a new file extension for EOT-
>Lite files? I presumed (perhaps incorrectly) that file extension itself
>may be part of the legacy we need to live with.

I'll double-check.

>Based on the working assumptions I had (see above) - better be safe than
>sorry. Checking flags (i.e. a single line of code) to make sure that you
>deal with valid font data is a small price to pay.

If one does not check the flags, the font data will not load so I don't see
this as safety as much as an optional optimization.


>Since the same spec is going to be used by those who implement support
>for EOT-Lite in a browser and by tool developers to generate legacy IE
>compatible font files - I think we have no choice but to disclose all
>relevant information about the EOT header.

Absolutely. It must be goal, however, that the part of the spec aimed at
user agent implementers be as simple as it can possibly be. We can't
require anyone to implement their own t2embed or anything close to it.

>We may not care about
>processing some of the data (e.g. the spec can advice browser
>implementers to skip some data fields) but I assume that for
>compatibility purposes the EOT header structure should be preserved.
>

Yes.


>I am not sure I understand your point here. If EOT-Lite file is properly
>formatted, what could possibly cause it not to load in IE? Would it be
>considered a break in compatibility?

Once all is said and done, one may still be able to contrive a file that loads in
non-IE browsers but not in IE. I'm stating I won't lose sleep over this possibility
as it is in the interest of the file producer to ensure the widest possible
compatibility of their product. I'm not interested in 'protecting' against the
possibility of stepping out of the proposal's core value which is compat with IE.

A simpler way to say it is that I don't want to ask Mozilla, Opera or anyone else
to go through elaborate steps to verify the content of EMBEDDEDFONT. Generating a header
that works well with IE is the job of the tooling. We want UAs to reach the font data
as fast as they can.


>
>Regards,
>Vlad

Received on Tuesday, 28 July 2009 14:51:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT