- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Thu, 30 Jul 2009 22:31:54 -0400
- 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. Vladimir
Received on Friday, 31 July 2009 02:32:18 UTC