Re: EOT-Lite File Format v.1.1 (and possibly v.1.2)

John Daggett wrote:
> (*) Values marked with an asterick are considered part of EOT-Classic
>     and do not affect load behavior or usage outside of legacy EOT
>     implementations.
> 
>   ULONG      EOTSize       Total structure length in bytes (including string and font data)
>   ULONG      FontDataSize  Length of the OpenType font (FontData) in bytes
>   ULONG      Version       Version number
>   ULONG      Flags         Processing flags
> * USHORT     Padding1[9]   Not used in EOT-Lite, see EOT-Classic [2]
>   USHORT     MagicNumber   Magic number for EOT file - 0x504C
> * ULONG      Padding2[7]   Not used in EOT-Lite, see EOT-Classic [2]
>   ULONG      Reserved[4]   Reserved for future use - 0 for this version
> * USHORT     Padding3      Not used in EOT-Lite, see EOT-Classic [2]
> * BYTE       Padding4[n]   Variable size, not used in EOT-Lite, see EOT-Classic [2]
>   BYTE       FontData[FontDataSize]
> [...]

How about just the following (EOT Lite v.1.2):

(ULONG is unsigned 32 bit little-endian integer, USHORT is unsigned 16
bit little-endian integer, BYTE is 8-bit unsigned integer)

(start of EOT Lite file)
ULONG EOTSize
 Total structure length in bytes (including string and font data)
ULONG  FontDataSize
 Length of the OpenType font (FontData) in bytes
BYTE Random1[20]
 Random bytes for EOT compatibility
USHORT MagicNumber
 Magic number for EOT file - 0x504C
BYTE Random2[n]
 Variable size, Random bytes for EOT compatibility, n >= 60
 if compatible with EOT
BYTE FontData[FontDataSize]
 The actual font

(Hopefully I got the lengths of random byte arrays correct...)

A conforming user agent would first execute same-origin check, then
verify that the MacicNumber is 0x504C. The font is activated by loading
the data at offset (EOTSize - FontDataSize) of length (FontDataSize) as
a normal OpenType font. If the font loads successfully, it will be used.

Same-origin check:

Before an EOT-Lite 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.

Consequences:

- The random bytes MAY be used to make the file compatible with various
versions of MSIE, including rootstring checks by MSIE if required by
some current font EULA. If compatibility with existing MSIE versions is
not required, all Random1 bytes SHOULD be set to zero and the length of
Random2 array SHOULD be also zero.

- Font data is broken if it has been XORed or MTX compressed. No need to
check for flags or version numbers, loading the font will just fail. (It
MUST be safe to try loading the scrambled font data as real data because
the font loading routine must be safe for any input. Otherwise, it's
just a security problem waiting to be exploited.)

- A conforming user agent could accidentally load existing EOT-Classic
font if such font does not contain any scrambling (XOR or MTX).
Hopefully such user agent would not be considered to be circumvention
device as defined by DMCA because there's no protection over the digital
data (except for the offset inside the file).


Note that I'm leaving any version number check explicitly out (other
than the MagicNumber which I'm leaving as an optimization). I'm hoping
that this format is used only for interoperability between user agents
including existing MSIE versions. Hopefully a better format with less
random bytes can be agreed upon in the future. This is explicitly about
creating the most simple format that can be compatible with existing
MSIE versions if authored suitably.

As for the name, I think EOTL is fine.

-- 
Mikko