W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: CSS3 @font-face / EOT Fonts

From: Thomas Phinney <tphinney@adobe.com>
Date: Tue, 4 Nov 2008 10:23:54 -0800
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <6D096C8718FA4241B934489A5E1CE1420118D9B1EF2D@nambx04.corp.adobe.com>

Robert O'Callahan wrote:

"Here Bert is presupposing that non-"free" fonts cannot be used as bare font
files, i.e., that the "font embedding" licensing cannot apply to bare font
files, but it can apply to EOT. That is in fact a core issue under dispute."

"As far as I know, font vendors have not been offered the option of bare font
files with same-origin restrictions, so it is unclear if font vendors oppose

As I read it, access control is designed to protect users, not content. Web sites merely need to add one additional word in their HTML/CSS code to avoid access control restrictions for each font used. Is this not correct? So if you include access control as a means of evading the same-origin restrictions, the restrictions are pretty non-existent. Why would type foundries consider this any different than bare font files without access control?

Speaking both for one of the larger font vendors, and as somebody who has spent literally scores of hours talking to and writing/reading message threads with other font vendors, I believe the lack of same-origin restrictions is only one part of most font vendors' thinking about this issue. It rarely comes up in discussion, perhaps because it is considered a given. My attempt a few days ago to ask font developers on the ATypI list about the access-control restriction was generally ignored, as these folks seem to be overwhelmingly lining up behind EOT.

What do they actually want? Commercial font vendors seem to mostly want at least these two things of web fonts:

1) That the *font file itself* or its wrapper be marked in a way that binds it to a given domain/URL. (A problem with naked fonts is that none of the existing fonts in the world are so marked, so any scheme that involves accepting existing unprocessed fonts without such markings is in a "closing the barn door after the horse has left" situation.)

2) That the web font file NOT work on Mac and Windows OS as a regular system-level font if dropped in the system fonts folder, without any other processing.

Most font vendors would *like* more protection/encryption than described above, but many and probably most could live with the two things above as a bare minimum.

My and Adobe's support for EOT is based on the idea that we want a web fonts solution that will satisfy the needs of web designers: the actual clients for the fonts. They overwhelmingly want to be able to use retail/commercial fonts. Preferably all such fonts, but even half of them would be better than just a handful, from their POV. So we seek a solution that will make most type vendors happy enough that they will be willing to license their fonts to be used with that solution. As far as I can tell, EOT is pretty much right at the minimum that will enable the licensing of most of the world's retail/commercial fonts. If it were substantially more restrictive than the minimum that font vendors will go for, then I'd be interested in doing something less restrictive. But that does not seem to be at all the case.


Received on Wednesday, 5 November 2008 09:13:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC