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

RE: EOT-Lite File Format

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Thu, 30 Jul 2009 22:31:54 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF297EF9F@wil-email-01.agfamonotype.org>
To: "Sylvain Galineau" <sylvaing@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "John Hudson" <tiro@tiro.com>
Cc: "Thomas Lord" <lord@emf.net>, <robert@ocallahan.org>, "John Daggett" <jdaggett@mozilla.com>, "www-font" <www-font@w3.org>
On Thursday, July 30, 2009 7:46 PM Sylvain Galineau wrote:
> >If the EOT file also qualifies as a valid EOTL file (which is very
> >possible), then it gets displayed.  If not, it doesn't, just like any
> >other random blob of data that doesn't comprise a recognized font
> >format.
> I think there is an interesting scenario there. Imagine I license
> an EOT from Monotype, set rootstrings then deploy it without
> compression
> or XOR encoding. If its version matches whatever existing EOT version
> EOTL settles on
> then it will load in the EOTL client despite the rootstring and
> possibly in violation
> of its license.

As I explained in one of my earlier messages, the license is unlikely to require a specific mechanism (be it root strings or same-origin or ...) be used. In the hypothetical example you presented you will do just fine - the root strings will be processed by IE (as you intended) while other UA will apply same-origin restriction by default.

> So either EOTL clients check for nil-rootstrings (wrecking the
> possibility of
> hijacking them for same-origin checks in legacy IE) or we use a new
> version number
> for EOTL to disambiguate the latter from EOT.
> Makes sense ?

Actually, I think it makes sense to completely ignore root strings, version numbers and all the fields that are irrelevant (defined as padding in John Daggett's draft). Browser will do a simple check to see if the data encoded in EOT file can be processed or not - if yes, the font is loaded.


Received on Friday, 31 July 2009 02:32:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:33 UTC