W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

EOT-Lite File Format 1.2 (was RE: EOT & DMCA concerns)

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Tue, 4 Aug 2009 15:09:41 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF297F19E@wil-email-01.agfamonotype.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Thomas Lord" <lord@emf.net>
Cc: "Thomas Phinney" <tphinney@cal.berkeley.edu>, "John Hudson" <tiro@tiro.com>, <www-font@w3.org>
Based on the Tab comment below I suggest that the latest proposal from John Daggett for EOT 1.1 format be modified to change the version number *only*. I believe that by using a unique EOT-Lite version number (and considering any previously used version of EOT format as non-EOT-Lite-compliant) we can avoid any and all possible pitfalls. In addition to enabling all EOT-Lite implementations to clearly differentiate EOT-Lite from any previous EOT versions, it will provide a clear path for IE9 to support EOT-Lite with same-origin + CORS. Tools that produce EOT-Lite fonts are required to use the new version number as well.

Here is a modified description copied from John's original email with the only change in applying the new, never previously used version number 0x00020003. I also added a sentence in the description of the fields marked with asterisk (*) to make it clear that they must be ignored.

Embedded OpenType Lite (EOT-Lite) File Format ===============================================

Below is a description of the EOT-Lite font wrapper.  It is intended as a platform-independent wrapper around OpenType font data.  It is designed to be compatible with versions of Microsoft Internet Explorer that support the EOT format, referred to here as EOT-Classic [2]. To generate a font compatible with EOT-Classic, refer to that specification.

All header values are little-endian.  Type names are based on those used in the OpenType specification [1].

(*) Values marked with an asterisk are considered part of EOT-Classic
    and do not affect load behavior or usage outside of legacy EOT
    implementations. 
    These values must be ignored by EOT-Lite compliant 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 (must be 0x00020003)
  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]

The Version field contains the version number.  The only valid version number currently is 0x00020003.

The Flags field contains a set of bit flags.  Only the values below are recognized in EOT-Lite, all other values are ignored:

  TTEMBED_TTCOMPRESSED               0x00000004
  TTEMBED_XORENCRYPTDATA             0x10000000

The process of activating an EOT-Lite font consists of (1) same-origin check (2) EOT-Lite header validation and (3) font validation and activation.  

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 [3].

EOT-Lite header validation:

After an EOT-Lite font has been downloaded, the header it validated:

1. Check that MagicNumber is 0x504C.
2. Check that the version number is 0x00020003.
3. Check that Flag bits TTEMBED_TTCOMPRESSED and TTEMBED_XORENCRYPTDATA are not set.

If any of these checks fail, the font is not loaded.  Except for the font data itself, no other field in the EOT-Lite header has any effect on either load or rendering behavior.

The font is activated by loading the data at offset (EOTSize -
FontDataSize) of length (FontDataSize) as a normal OpenType font.  The steps required to validate OpenType font data are intentionally not described here since those are more the domain of the OpenType specification [1] and validation steps may change as new security threats emerge.

[1] OpenType specification - http://www.microsoft.com/typography/otspec/


[2] EOT-Classic - http://www.w3.org/Submission/EOT/

    Note: the version described as version 0x00010000 is actually
    version 0x00020000, the version used in EOT-Lite fonts.

[3] CORS specification - http://www.w3.org/TR/access-control/



On Tuesday, August 04, 2009 1:58 PM Tab Atkins Jr. wrote:
> 
> On Tue, Aug 4, 2009 at 12:38 PM, Thomas Lord<lord@emf.net> wrote:
> > Poor Dagget might eventually find that Firefox has
> > had an EOTL bug for a year or two that results in
> > the accidental rendering of some EOTC fonts.  Worse,
> > perhaps resulting in some number of sites "in the wild"
> > that rely on this bug.
> 
> This is a possibility.  However, it will likely suffice just to ensure
> that the common EOT-producing programs produce files in a format
> distinguishable from EOTL.
> 

Received on Tuesday, 4 August 2009 19:10:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT