- From: Richard Fink <rfink@readableweb.com>
- Date: Fri, 31 Jul 2009 12:36:51 -0400
- To: "'John Hudson'" <tiro@tiro.com>, "'Levantovsky, Vladimir'" <Vladimir.Levantovsky@MonotypeImaging.com>
- Cc: "'Thomas Lord'" <lord@emf.net>, "'Thomas Phinney'" <tphinney@cal.berkeley.edu>, "'Sylvain Galineau'" <sylvaing@microsoft.com>, "'Tab Atkins Jr.'" <jackalmage@gmail.com>, <robert@ocallahan.org>, "'John Daggett'" <jdaggett@mozilla.com>, "'www-font'" <www-font@w3.org>
Friday, July 31, 2009 John Hudson <tiro@tiro.com>: John, (I've been battling a dental infection the past two days so I might be missing a fine point you're trying to make, my apologies in advance if that's the case...) To put it plainly, as of IE 9, licenses will have to be redrafted as will anything and everything predicated on IE's continued support for EOT classic. There is no way for feature-by-feature support for both to exist in tandem. There will be breakage. Downlevel IE versions will be able to read EOTL but the converse won't be true. And as Vlad points out in a later post, EOT classic files will likely have MTX and XOR anyway, and will have to be re-made. >I'm not a lawyer, but it seems to me that a browser that fails to follow >this when encountering an EOT-Classic font is at legal risk. Since, as a practical matter, in >IE8 certain features of EOT CL will be obsolete and you'll need new files, where does a problem arise? And as a non-lawyer who's better-read than most on the pertinent case law, I don't see any risk even if the files didn't need to be re-made. I echo what Thomas Phinney said on this. Regards, rich -----Original Message----- From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Hudson Sent: Friday, July 31, 2009 2:20 AM To: Levantovsky, Vladimir Cc: Thomas Lord; Thomas Phinney; Sylvain Galineau; Tab Atkins Jr.; robert@ocallahan.org; John Daggett; www-font Subject: Re: EOT-Lite File Format Vladimir wrote: > As I understand what the current draft says > (http://lists.w3.org/Archives/Public/www-font/2009JulSep/0780.html), the > EOT-Lite conforming UA will render a font if it's capable to do so, > regardless of the presence of rootstring (i.e. completely ignoring the > root strings, whether mismatched or not). It makes sense that the EOT-Lite proposal makes such a statement about EOT-Lite fonts. But, again, this presumes a distinction can be made between EOT-Lite and EOT-Classic fonts when encountered in the wild, because ignoring the rootstrings in a format that deliberately states that rootstrings should be ignored is different from ignoring rootstrings in a format that deliberately states that User Agents must validate that the page using the embedded font is within the list of URLs from which the embedded font object may be legitimately referenced. [1] I'm not a lawyer, but it seems to me that a browser that fails to follow this when encountering an EOT-Classic font is at legal risk. If not, why all the fuss about DMCA? At the very least, this seems to me a question that needs to be examined by qualified lawyers experienced with this kind of issue. At present, the non-IE browser makers are deliberately not touching EOT fonts because they don't want to get entangled with the rootstring issue. They're not supporting EOT but ignoring rootstrings: they're keeping the heck away from EOT altogether. It seems to me that they must continue to do so, because the status of EOT Classic fonts doesn't magically change when EOT Lite comes along. This means that while EOT Lite fonts can be backwards compatible with IE<=8, EOT Classic fonts must not be forwards compatible with EOT Lite. Somehow the two formats need to be clearly distinct at the file level, such that an EOT Lite implementing browser can process the one but avoid the other. JH [1] http://www.w3.org/Submission/2008/SUBM-EOT-20080305/#RootString
Received on Friday, 31 July 2009 16:37:40 UTC