RE: EOTL font file specification version 1

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.

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.

Regards,
Vlad


 

> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Mikko Rantalainen
> Sent: Thursday, August 06, 2009 5:27 AM
> To: www-font
> Subject: RFC: EOTL font file specification version 1
> 
> Request for comments:
> 
> See my previous post:
> http://lists.w3.org/Archives/Public/www-font/2009JulSep/1206.html

> 
> I thought about this a bit more and perhaps we should drop all
> non-critical legacy features from EOT Lite and rename it as e.g. "EOTL
> font format" or "SEOT font format" (the latter standing for Simplified
> EOT) or PBCWF (Possibly Backwards Compatible Web Font). I'll refer to
> new font format as EOTL font below.
> 
> ****
> 
> The EOTL font file specification (version 1)
> 
> File starts with a two consecutive 32 bit little endian unsigned
> integer
> numbers. The first is called EndOffset and the second is called
> PayloadSize. Before trying to load an EOTL font file, a conforming user
> agent must first execute Same-origin check and if that fails, consider
> the font as invalid.
> 
> Same-origin check:
> 
> Before an EOTL font is downloaded either of the conditions below
> must be true:
> 
> 1. The font originates from the same origin as the containing document
> 2. The site serving the font relaxes the restriction above using an
>    Access-Control-Allow-Origin HTTP response header as described in the
>    Cross-Origin Resource Sharing specification.
> 
> If the Same-origin check is successful, a conforming user agent will
> download the font. Then the font is activated by loading the data at
> offset (EndOffset - PayloadSize) of length (PayloadSize) as a normal
> OpenType font. If the font loads successfully, it will be used.
> Otherwise, consider the font as invalid.
> 
> ****
> 
> As I see it, the EOTL specification does not need to say anything more.
> It could mention in the informal part that the bytes between byte 8 and
> offset (EndOffset - PayloadSize) can be used for compatibility with
> legacy user agents.
> 
> If compatibility with legacy user agents (MSIE) is not required, the
> EOTL font file is identical to OpenType with eight byte prefix computed
> from the size of the original OpenType font file (EndOffset is set to
> size of Original OpenType font + 8, PayloadSize is set to the size of
> original OpenType font, followed by contents of original OpenType font
> file).
> 
> The OpenType font data can be extended with additional tables to
> contain
> any meta information about the font as needed by font
> author/distributor.
> 
> In the end, any EOT classic font without XOR or MTX scrambling can be
> loaded successfully with Same-origin/CORS restrictions with conforming
> user agents. A compatible (but non-conforming) legacy agent (MSIE) can
> load the EOT classic font as usual (no Same-origin restrictions but
> rootstrings or other restrictions in the EOT classic font may apply).
> 
> Pros:
> 
> - Really easy to implement (similar to raw OTF except for the offset).
> - Does not require any EOT specific knowledge or magic numbers from
> conforming user agent.
> - Compatibility with MSIE.
> 
> Cons:
> 
> - Undermines the "protection" provided with rootstrings in current EOT
> files (though, I'd assume that most EOT files with rootstrings also
> include XOR or MTX scrambling and would not be successfully loaded).
> 
> --
> Mikko

Received on Thursday, 6 August 2009 15:09:26 UTC