- From: John Daggett <jdaggett@mozilla.com>
- Date: Mon, 27 Jul 2009 13:22:14 -0700 (PDT)
- To: www-font <www-font@w3.org>
I looked again over the EOT submission [1] over the weekend. The EOT header contains a number of fields whose definition is not very clear to me. Which of those fields/values are considered part of EOT-Lite and what are their defined behaviors? In one sense I could see a simple implementation of EOT-Lite being verify the MagicNumber field, then simply use the EOTSize and FontDataSize to calculate where the underlying font data is and load it. Many of the fields in the header are duplicated from data in the font itself. Are there other fields that affect load and/or usage behavior, ones that are intended to result in different load/usage behavior compared to just loading the font data itself? And where is the separation between "legacy" behavior (i.e. the way IE behaves today) and "standard" behavior (the way all browsers should act across platforms)? For example, the original EOT submission blurred the meaning of OpenType embedding bits to imply behavior within the browser (i.e. with Print/Preview set the user agent must not allow editing with a font). At the TPAC meeting last fall [2] it was suggested that these were intended to be used for authoring tools only. Are any of the processing bits intended to have defined behavior, TTEMBED_FAILIFVARIATIONSIMULATED for example? Obviously, TTEMBED_TTCOMPRESSED is ignored but what about TTEMBED_EMBEDEUDC and TTEMBED_XORENCRYPTDATA? Bill, Sylvain? Cheers, John [1] http://www.w3.org/Submission/EOT/ [2] http://www.w3.org/Fonts/Misc/minutes-2008-10
Received on Monday, 27 July 2009 20:22:54 UTC