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

Re: EOT-Lite File Format

From: Thomas Lord <lord@emf.net>
Date: Thu, 30 Jul 2009 17:09:42 -0700
To: John Daggett <jdaggett@mozilla.com>
Cc: www-font <www-font@w3.org>
Message-Id: <1248998982.6257.113.camel@dell-desktop.example.com>
On Thu, 2009-07-30 at 16:31 -0700, John Daggett wrote:
> Thomas Lord wrote:
> > > EOT-Lite header validation:
> > 
> > > 1. Check that MagicNumber is 0x504C.
> > > 2. Check that the version number is either 0x00010000, 0x00020001, or 0x00020002.
> > > 2. Check that Flag bits TTEMBED_TTCOMPRESSED and TTEMBED_XORENCRYPTDATA are not set.
> > >
> > > If any of these checks fail, the font is not loaded.  The font is
> > > activated by loading the data at offset (EOTSize - FontDataSize) of
> > > length (FontDataSize) as a normal OpenType font.
> > [Regarding your second item #2 as #3, as presumably
> > intended.]
> Argh, yes.
> > When you say "the font is not loaded" do
> > you mean MUST, MAY, or SHOULD?
> For implementations *only* supporting EOT-Lite, the font is not
> loaded.  No exceptions. 

I think we have a problem there.  What you describe
is a DRM-via-standards mechanism - the very problem
that EOT-lite supposedly cures.   This is probably
a minor problem rather than one that needs to cause
a split (is my take on the tone and content of the

>  May the Lord strike you down if you do (pun
> intended). 

The other one people like to use are puns based
on the famous actor Jack Lord of the old TV show
Hawaii 5-0.  Also, Google tells me that Thomas
Lord is a famous porn store, apparently of somewhat
infamous physiological proportions in some regards --
no affiliation.  I suspect that the surname was 
adopted somewhere in the 19th or 20th centuries as,
indeed, a kind of joke but I'm not sure - I just
inherited it.  The lifelong experience that is kind
of amusing is the frequency of occurrences of people
taking down my name and clearly reacting as if "Oh,
that's got to be a fake name."  Go figure.

> > If EOT-lite becomes the recommendation, is the
> > previously discussed patent de-encumberence of MTX
> > included in the deal?

> No, as currently defined EOT-Lite does not include MTX compression.

That's something that will come up as things move
forward.  I think that's a problem.  Can we hear
from Monotype on that?  Maybe they wouldn't mind
if MTX patents became safe to implement if EOT-lite
is adopted.  Otherwise, we wind up with an arguably
discriminatory Recommendation.

> > Similarly, all three checks should be stated affirmatively rather
> > than negatively.  If the magic number and version numbers check out
> > and if the flag bits of interest are 0 then the browser MUST render
> > the font.  That is importantly different from "MUST NOT" in the case
> > where those checks don't pass.

> Whether the font is loaded will naturally be based on
> implementation-specific validity checks.  It's not possible to list
> all possible validity checks, this will change as threats occur.
> Conversely, things like bad head table checksums are probably not part
> of these validity checks since no font tool seems to view these as
> a validity problem.

Positive assertions ("MUST render when ....") are better
than negative ("MUST NOT render when ....").

Received on Friday, 31 July 2009 00:10:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:40 UTC