- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Mon, 27 Jul 2009 21:57:00 +0000
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
> 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. > 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 ? :) > 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. 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.
Received on Monday, 27 July 2009 21:57:43 UTC