Re: EOT-Lite File Format

Thomas Lord wrote:

> > EOT-Lite header validation:
> 
> > 1. Check that MagicNumber is 0x504C.
> > 2. Check that the version number is either 0x00010000, 0x00020001, or 0x00020002.
> > 2. Check that Flag bits TTEMBED_TTCOMPRESSED and TTEMBED_XORENCRYPTDATA are not set.
> >
> > If any of these checks fail, the font is not loaded.  The font is
> > activated by loading the data at offset (EOTSize - FontDataSize) of
> > length (FontDataSize) as a normal OpenType font.

> [Regarding your second item #2 as #3, as presumably
> intended.]

Argh, yes.

> When you say "the font is not loaded" do
> you mean MUST, MAY, or SHOULD?

For implementations *only* supporting EOT-Lite, the font is not
loaded.  No exceptions.  May the Lord strike you down if you do (pun
intended).  For implementations supporting EOT-Classic, that's a
question for those reading the source of t2embed.  Happy reading!

> If EOT-lite becomes the recommendation, is the
> previously discussed patent de-encumberence of MTX
> included in the deal?

No, as currently defined EOT-Lite does not include MTX compression.

> Similarly, all three checks should be stated affirmatively rather
> than negatively.  If the magic number and version numbers check out
> and if the flag bits of interest are 0 then the browser MUST render
> the font.  That is importantly different from "MUST NOT" in the case
> where those checks don't pass.

Whether the font is loaded will naturally be based on
implementation-specific validity checks.  It's not possible to list
all possible validity checks, this will change as threats occur.
Conversely, things like bad head table checksums are probably not part
of these validity checks since no font tool seems to view these as
a validity problem.

Received on Thursday, 30 July 2009 23:32:11 UTC