Re: EOTL font file specification version 1

Levantovsky, Vladimir wrote:
> I think we ought to consider the following:
> 
> 1) How would UA know whether the downloaded file is in fact EOTL? The
> file extension could be misleading, and the perfectly valid EOTL file
> could be named with different file extension. This is why I think
> that checking magic number would be necessary just to make sure that
> you can safely use first two 32-bit numbers to calculate the size and
> offset.

Any browser dealing with bytes coming from Internet should assume
intended malice. As such, checking for magic number would not make it
"safe" to use first two 32-bit numbers to calculate anything. Safety
measures should be implemented regardless of the given input. (e.g. it's
safe to check if the integers from two 32-bit numbers are within the
range of the given file and if there seems to be OpenType font data
within that range. It's not safe to blindly use those memory locations
if a magic number is correct.)

The user agent is expecting to find a valid OpenType font data at given
offset and as far as I know, OpenType files can already be identified.
There's no special need for identifying the wrapper format as is
(because it cannot wrap anything but OpenType font file as specified).

I did suggest keeping the magic number in my first post but I believe
that it is not necessary. As a result, I suggested an even simpler
specification.

I'm trying to suggest *an absolute minimum specification* that allows
*conforming* user agents to successfully load EOTL fonts. The fact that
the specification allows leaving additional bytes between the 8 byte
header and the font payload does not need to be explained in the formal
specification. It's not important to conforming user agent. It's only
meaningful for content authors trying to create a file that is a
conforming EOTL font file and a valid EOT classic font file in the same
time. I'm totally aware that this possibility is the whole reason to
ever use EOTL for anything but I'm arguing that if W3C is going to
specify something, it should specify minimum required for
interoperability - which is EOTL as I specified in my previous post
(http://lists.w3.org/Archives/Public/www-font/2009JulSep/1232.html)

There's no need for version numbers, feature flags or magic numbers
because the font data can be found using only the first 8 bytes from the
file. Checking for version numbers, feature flags or magic numbers
cannot guarantee that the font data can be loaded (e.g. it could be
corrupted by mistake or because of malice).

> 2) Yes, it is possible to assume that any payload of EOTL file is a
> TTF/OTF font, and hope that if the assumption is wrong the UA will
> take care of it. But the code that processes the EOTL is the part of
> UA itself, and it just makes sense that, as the first step of
> checking the font data validity, UA will check the flags that
> indicate whether a font was subjected to obfuscation and/or
> compression. If yes, UA would consider a font invalid without loading
> or even looking at actual font data.
> 
> If one agrees that these first two steps are useful and reasonable,
> then you need to know the location of the magic number and flags in
> the file header. Any data that is stored in between is treated as
> padding, which is put there only for backward compatibility purposes
> and to be ignored by EOTL implementations.

I'd would assume that the OS/font subsystem that is trying to load the
OpenType font already checks if the input file is indeed a valid
OpenType font. Any additional checks before that are wasted CPU time for
a valid font file. And hopefully the OS/font subsystem is sane enough to
immediately return if an error is found. So that is not an optimization
even for invalid fonts. (There can be additional optimizations but none
of those need to be codified by the specification.)

If some operating system does require additional checks before an
OpenType font file can be safely passed to it, then an user agent
running on that system must figure it out. However, such checking does
not to be specified in the web font format.

-- 
Mikko