RE: A way forward (was: Webfont compression)

Thursday, July 23, 2009 John Hudson <tiro@tiro.com>:

>if it meant taking naked font linking off the table completely

John,

If by this, you mean a discontinuation of support for linking to "raw" TTF/OTF in Safari and FF, replaced by support for a .webfont of some kind, it's not going to happen. Nor should it, IMHO. When it comes to backward compatibility, I believe in "stare decisis" - people order themselves around previous decisions by software makers to support this or that, and unless there is complete obsolescence or some other outstanding reason to discontinue support, you just keep on going with it. That cat's not going back into the bag.
However, on the flip side, putting myself in MSFT's shoes, with all they've spent on fonts and the competitive advantage it brings, I simply don't see how anyone in the company could justify raw linking. I mean, what do you tell the stockholders? "Well, we spent all this money and then, for no particularly good reason, we gave the product away." Each browser company has its stakeholders to answer to, each in its own way.
Just my take.

Cheers,

rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Hudson
Sent: Thursday, July 23, 2009 9:37 AM
To: www-font@w3.org
Cc: www-font
Subject: A way forward (was: Webfont compression)

Tab Atkins Jr. wrote:

> We've been over this before, JD.  We know that the IE upgrade and
> uptake cycles are longer than for any other browser, thus any solution
> that means IE has to support something new is automatically
> handicapped by a 5+ year wait for it to be useful to us.  (I can
> convince the Advertising department to accept IE users not getting
> pretty rounded corners - I have not so far been able to convince them
> to accept IE users not getting the pretty font they want in our
> headers.) 

You would retain the option of serving dual formats: .eot to IE and 
.webfont to other browsers. Even when a new version of IE supports 
.webfont, you may still want to serve .eot for older versions that will 
probably linger in use for many years.

While some font makers favour .webfont and some an EOT-derived format 
(with URL binding removed and the MTX patents released), the impression 
I get is that most of my colleagues would be willing to license fonts 
for either or both. Both formats provide the kind of simple protection 
and distinction from desktop fonts that we are looking for. The one 
thing that the overwhelming majority do not want to do is license for 
naked font linking.

If Mozilla intends to resist anything EOT-derived, and if Microsoft and 
most professional font makers intend to resist naked font linking, that 
makes .webfont the only viable path to an interoperable standard that 
doesn't involve a protracted, knock-down drag-out fight.

I'm sympathetic to your position, Tab, since I'm one of the font makers 
who currently favours an EOT-derived format for its backward 
compatibility. But I'd be willing to forego that compatibility if it 
meant taking naked font linking off the table completely, and focusing 
on .webfont as the interoperable format. In other words, if we take off 
the table what Mozilla finds objectionable and also take off the table 
what Microsoft and the font makers find objectionable, we are left with 
.webfont as a viable format and a reasonable political compromise.

IE would presumably continue to support EOT alongside .webfont, and 
other browsers will presumably continue to support naked font linking 
for those free fonts whose makers are willing to permit that format. But 
we'd give up on what seems to me the increasingly untenable idea that 
either of these is going to become a broadly interoperable format.

John Hudson

Received on Thursday, 23 July 2009 14:53:24 UTC