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

Re: EOT-Lite File Format

From: Thomas Lord <lord@emf.net>
Date: Thu, 30 Jul 2009 17:26:23 -0700
To: John Hudson <tiro@tiro.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "robert@ocallahan.org" <robert@ocallahan.org>, John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
Message-Id: <1248999983.6257.119.camel@dell-desktop.example.com>
On Thu, 2009-07-30 at 16:56 -0700, John Hudson wrote:
> Tab wrote:

> I kind of assumed that EOTL clients would check for nil rootstrings, and 
> that a non-nil rootstring would make it an invalid EOTL.

The maxim "Be tolerant in what you receive, strict in what
you transmit" applies here.

According to that maxim, a Recommendation MUST NOT say
"MUST NOT render" on the flimsy excuse of a non-nil 
root string - but a Recommendation probably SHOULD say
"MUST render" for the case of a nil root string.

> Whatever else it is, an EOT Lite font is a font with a nil rootstring 
> [at the moment, it is also a font with no compression, but I'm really 
> hoping that we can get this to a working group stage and satisfy 
> Monotype's criteria for releasing the MTX patented compression].

[amen to your [...]]


> Font makers are going to be licensing fonts for EOTL format linking, not 
> EOT linking. And most of those makers, I suspect, will also be providing 
> the EOTL files to the customer. Microsoft's original EOT model, whereby 
> which the web author created his own .EOT files from TTFs only made 
> sense because of the rootstrings and content-specific subsetting, 
> particular to the use of the font on specific websites. Since there are 
> no rootstrings in EOTL, and content-specific subsetting is no longer 
> viable since web content is now a lot more dynamic than it was in 1990, 
> I anticipate .EOTL -- or any other web font format -- being primarily a 
> delivery format from font makers to licensees of web fonts.
Received on Friday, 31 July 2009 00:27:03 UTC

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