- From: Thomas Phinney <tphinney@cal.berkeley.edu>
- Date: Thu, 30 Jul 2009 20:15:24 -0700
- 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 UTC