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

RE: EOT-Lite clarification

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Tue, 28 Jul 2009 10:40:26 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF297EDDD@wil-email-01.agfamonotype.org>
To: "Sylvain Galineau" <sylvaing@microsoft.com>, "John Daggett" <jdaggett@mozilla.com>, "www-font" <www-font@w3.org>
On Monday, July 27, 2009 5:57 PM Sylvain Galineau wrote:
> To: Levantovsky, Vladimir; John Daggett; www-font
> > I do not see why one would even have to check that rootstring is
> null.
> > Would it be easier just ignore it no matter what (if anything) is in
> > there? And, if this is what the spec say browser should do (i.e.
> ignore
> > rootstring), I don't see anything wrong with it, it just makes
> > implementer's life easier.
> I'd think anyone who licenses EOT-Classic fonts (as opposed to EOT-
> Lite)
> expects the rootstring to be enforced. Even if Monotype doesn't care it
> would be quick check, combined with a file extension, indicating that
> you're dealing with a valid EOT-Lite file and can go straight to the
> font
> data. No MTX compression or any other legacy feature in your way.

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 would imagine that some flags need to be checked to make sure that
> > you are in fact working with EOT-Lite.
> I thought we were trying to make things simpler for implementers ? :)

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. 

> > For example, you probably want
> > to check that TTEMBED_TTCOMPRESSED flag is not set to make sure that
> > you are dealing with uncompressed font data, and to check
> > TTEMBED_XORENCRYPTDATA flag to know what (if anything) to do with it.
> I
> > am not sure if we should explicitly disallow XOR encryption, or if we
> > can live with it since it may qualify as simple obfuscation.
> I suggest a distinct file extension and a null rootstring to do the
> job. The less
> Implementers need to know about the legacy data in the header, the
> better. Only those
> who generate font files need to bother generating something that IE
> understands. If it
> works in IE, it must work in all the other user agents.

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

> As the main benefit of this proposal is compatibility with IE, I assume
> we do not care about
> the scenario where the file would not load in IE due to legacy behavior
> but would work in Firefox
> or Opera.

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?


Received on Tuesday, 28 July 2009 14:41:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:33 UTC