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

Re: EOT-Lite File Format

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 30 Jul 2009 18:51:57 -0500
Message-ID: <dd0fbad0907301651y78faaf13k7916a2806059c1fb@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: John Hudson <tiro@tiro.com>, Thomas Lord <lord@emf.net>, "robert@ocallahan.org" <robert@ocallahan.org>, John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
On Thu, Jul 30, 2009 at 6:46 PM, Sylvain Galineau<sylvaing@microsoft.com> 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
> 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.
> 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 ?

What's the effect on legacy IE of a new version number?

Received on Thursday, 30 July 2009 23:52:52 UTC

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