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

RE: EOT-Lite File Format

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Fri, 31 Jul 2009 12:09:02 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF297EFDF@wil-email-01.agfamonotype.org>
To: "John Hudson" <tiro@tiro.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>
On Friday, July 31, 2009 2:20 AM John Hudson wrote:
> 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
> that needs to be examined by qualified lawyers experienced with this
> kind of issue.

If the behavior of EOT-Lite client matches what I described in my
previous email, then ignoring root strings poses no risk at all. As far
as EOT-Classic is concerned, I would consider the current EOT
specification as an "FYI" document, it is only a proposal and not an
official standard, and cannot be enforced in any way. The only document
that may ever get to the point when it can become a Recommendation is
yet-to-be-written EOT-Lite specification.

> At present, the non-IE browser makers are deliberately not touching
> 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.

I believe that the distinction line will be drawn based on capabilities
of the client to process a font; otherwise (again, based on the
reasoning I presented in my email earlier) I believe that simply
ignoring certain fields in EOT header is the best way to achieve truly
interoperable solution.


> JH
> [1] http://www.w3.org/Submission/2008/SUBM-EOT-20080305/#RootString
Received on Friday, 31 July 2009 16:09:47 UTC

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