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

RE: EOT-Lite clarification

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Mon, 27 Jul 2009 17:40:32 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF297EDB0@wil-email-01.agfamonotype.org>
To: "Sylvain Galineau" <sylvaing@microsoft.com>, "John Daggett" <jdaggett@mozilla.com>, "www-font" <www-font@w3.org>
On Monday, July 27, 2009 5:22 PM Sylvain Galineau wrote:
> John Daggett wrote:
> > In one sense I could see a simple implementation of EOT-Lite being
> > verify the MagicNumber field, then simply use the EOTSize and
> > FontDataSize to calculate where the underlying font data is and load
> > it.  Many of the fields in the header are duplicated from data in the
> > font itself.  Are there other fields that affect load and/or usage
> > behavior, ones that are intended to result in different load/usage
> > behavior compared to just loading the font data itself?  And where is
> > the separation between "legacy" behavior (i.e. the way IE behaves
> > today) and "standard" behavior (the way all browsers should act
> > across platforms)?
> Checking for this at the source. For me, the only behavior to agree on
> is the minimum set of steps necessary to decide that the raw font file
> following the EMBEDDEDFONT struct can be installed for use by the UA. 
> One of these steps being that its rootstring must be null. (As I assume 
> you do not want to be in the business of loading all EOTs, including 
> those with rootstrings).

I do not see why one would even have to check that rootstring is null. Would it be easier just ignore it no matter what (if anything) is in there? And, if this is what the spec say browser should do (i.e. ignore rootstring), I don't see anything wrong with it, it just makes implementer's life easier.

> >
> > For example, the original EOT submission blurred the meaning of
> > OpenType embedding bits to imply behavior within the browser (i.e.
> with
> > Print/Preview set the user agent must not allow editing with a font).
> > At the TPAC meeting last fall [2] it was suggested that these were
> > intended to be used for authoring tools only.  Are any of the
> > processing bits intended to have defined behavior,
> > TTEMBED_TTCOMPRESSED is ignored but what about TTEMBED_EMBEDEUDC and
> Stand by...

I would imagine that some flags need to be checked to make sure that you are in fact working with EOT-Lite. For example, you probably want to check that TTEMBED_TTCOMPRESSED flag is not set to make sure that you are dealing with uncompressed font data, and to check TTEMBED_XORENCRYPTDATA flag to know what (if anything) to do with it. I am not sure if we should explicitly disallow XOR encryption, or if we can live with it since it may qualify as simple obfuscation. 


Received on Monday, 27 July 2009 21:42:03 UTC

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