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

Re: EOT-Lite File Format

From: Thomas Phinney <tphinney@cal.berkeley.edu>
Date: Thu, 30 Jul 2009 20:15:24 -0700
Message-ID: <f49ae6ac0907302015w77563f84hd821bfdeb3d7ebb5@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Hudson <tiro@tiro.com>, Thomas Lord <lord@emf.net>, robert@ocallahan.org, John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
On Thu, Jul 30, 2009 at 7:31 PM, Levantovsky,
Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> 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.

I should point out that it was my suggestion that a browser could
simply reject rendering of a font that had root strings. My reason for
suggesting that was Hakon's concern that a browser that simply ignored
the root string could open itself up to DMCA action or some such.

However, if the context is a font whose version string matches EOTL
and not EOT, and there is an actual written EOTL specification that
says the field should be ignored, I have difficulty imagining there
would be a real concern about ignoring the root string field.

Regards,

T
Received on Friday, 31 July 2009 03:21:12 GMT

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