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

RE: CSS3 @font-face / EOT Fonts

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 7 Nov 2008 15:36:25 +0000 (UTC)
To: Thomas Phinney <tphinney@adobe.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.62.0811071526191.1041@hixie.dreamhostps.com>

On Wed, 5 Nov 2008, Thomas Phinney wrote:
>
> I agree that those are the constituents browser vendors should be 
> looking out for. But "plain old TTF/OT files" do NOT meet the needs of 
> developers. The logic is simple.
> 
> 1) Developers (especially designer-developers) dearly want to be able to 
> use any font at all, and they want to be able to do so legally. They 
> value "retail" fonts and don't want to be stuck using only 
> shareware/freeware/open-source fonts. We know this from several hundred 
> responses to surveys aimed at end users.

The solution to this is exactly the same solution as has been found by 
stock photo distributors, people who write content, people who generate 
templates for HTML/CSS, etc. Licensing. This is not a new problem.


> 2) The folks who make the retail fonts want exactly the two kinds of 
> protections in question, which requirements are met by EOT and 
> apparently by the compromise proposal as well. The minimum requirement 
> seems to be: URL info in the font, plus just enough obfuscation that the 
> font can't work in Mac or Windows without pre-processing. That minimum 
> will get a critical mass of retail fonts available: many font makers 
> would like a LOT MORE than this, but we could probably get > 1/2 of all 
> retail fonts with just these two elements. We know this from spending 
> scores of hours talking to font developers.

If we don't provide this, then we are creating a new market for font 
vendors who care about their customers and are willing to produce high 
quality fonts that are not restricted in the inane way proposed. We know 
there are font vendors willing to create fonts for this market, they 
already do (e.g. Ascender Corp produced a series of three unrestricted 
fotns for Google's Android platform).


> So, if you want to meet the needs of web developers, you need to satisfy 
> the requirements of the folks who make the majority of retail fonts out 
> there, which means exactly these two elements you are so unexcited 
> about.

No, we don't. Foundries will adapt, just like music labels have adapted, 
just like independent movie studios have adapted, and just like many game 
producers have adapted.


> Could be. But the concern of most font makers is not keeping fonts 
> locked in a perfect vault, just keeping the strong majority of users 
> honest.

The majority of users ARE honest. In fact, as EA discovered recently with 
Spore, DRM technologies actively encourage copyright and license 
violations. If these companies really care about their users being honest, 
they wouldn't use DRM technologies.


> I personally, and folks from most font foundries, believe that even 
> light obfuscation which requires some special tool to break it, will 
> achieve that goal.

Then, with all due respect, you are wrong.


> If people want to actively pirate fonts and strip DRE information out of 
> them, they can and will. But having such info in the fonts there means 
> that people will have to knowingly do something that most people think 
> is wrong, and experience (PDF, SWF) and survey data both suggest that 
> most people won't go so far.

Experience shows that the more desireable the product, the more DRM will 
cause them to violate the license.


> > DRM is evil. Easily-circumvented DRM is pointless and evil.
> 
> I believe this isn't DRM, but DRE (and even more so in the new 
> "compromise proposal"). But of course calling it DRM makes it easier for 
> W3C folks to have a knee-jerk reaction against it.

DRE is evil. Easily-circumvented DRE is pointless and evil.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 7 November 2008 15:37:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:16 GMT