Re: EOT-Lite File Format v.1.1

Tab Atkins Jr. wrote:

> > 1. Check that MagicNumber is 0x504C.
> > 2. Check that the version number is 0x00020000.
> > 3. Check that Flag bits TTEMBED_TTCOMPRESSED and TTEMBED_XORENCRYPTDATA are not set.
> 
> If a file fails these checks, MUST it refuse to load the file, or
> can a conforming implementation attempt to parse it as a different
> file?
> 
> That is, do these checks occur past the point of no return, or can
> they be part of the "check what kind of font this file is"
> algorithm, allowing a conforming implementation to then attempt to
> load it as a different kind of font (such as EOT-Classic)?

It must refuse to load it as an EOT-Lite font but whether it could
load it as something else would depend.  Since multiple acceptable
formats exist and will continue to exist (e.g. SVG fonts), I think
there will always some process of loading it as something else.  But
this gets into content sniffing and whatever happens here needs to
follow those general rules.

The 'format' hint of the @font-face rule also plays a rule.  The
format hint restricts the possible formats a file can be loaded as. 
It allows user agents that don't support a given format (e.g. "svg")
to avoid downloading data in this format.

@font-face {
  font-family: Laughing Babies;
  src: url(http://site/path/file) format("eotlite");
}

In this case the font should *never* load as anything other than an
EOT-Lite font.  Without a format than some set of MIME checking and
format sniffing probably applies.

We should probably register a MIME type for EOT-Lite (e.g.
application/font-eotlite).

Received on Friday, 31 July 2009 19:59:28 UTC