RE: EOT-Lite clarification


> 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)?

Checking for this at the source. For me, the only behavior to agree on is
the minimum set of steps necessary to decide that the raw font file following
the EMBEDDEDFONT struct can be installed for use by the UA. One of these
steps being that its rootstring must be null. (As I assume you do not want
to be in the business of loading all EOTs, including those with rootstrings).

IE CSS parser bugs such as the one brought by Hakon are most definitely
out of scope here; there are no benefits in specifying, standardizing or
emulating such bugs for authors, font or browser vendors, whether for font
support generally or EOT-Lite specifically. (Although I very much doubt the
latter would even be possible given that EOT-Lite and OTF/TTF could be fallbacks
for one another...)

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

Stand by...

Received on Monday, 27 July 2009 21:22:38 UTC