RE: Next step?

As I yet have to see evidence that ‘most font licenses will require…some kind of same-origin restriction’, as well as the exact language supporting that requirement, claims of pointlessness deferred from this assumption should be considered a statement of opinion at this time.

Second, if same-origin control is a strong requirement for the success of a web font format then it should also be specified by this WG. Today, to my knowledge, only Firefox and IE support a form of origin control for web fonts. If CWT is ‘pointless’ for lack of it – or merely because it makes it harder - then unrestricted raw fonts – which no commercial font designer wants to touch, same-origin policy or not – should be considered at least as useless. Yet I do not see their utility and relevance to the charter being contested here (modulo John Hudson). Care to elaborate why that’s the case ?

Third, the question is not whether you or I see value in it, but whether authors and therefore font vendors do. I honestly didn’t think font vendors would be happy with a mere prefix to a raw TTF. Neither did John Daggett, as far as I know. But they have not only expressed strong interest, one of them – Ascender – actively promoted the idea. And still does, despite your repeated claim of uselessness. I would therefore not prejudge the possible value of this. It is a big marketplace and the actors, to their collective credit, are moving and evolving. A year ago, after all, people you and I both know asserted – in my presence - that raw fonts were all there needed to be, and likely all there would be for some time. That font vendors should either come around or deserved to go the way of dinosaurs. As for font vendors, some effectively assumed something akin to DRM was absolutely necessary and the catchphrase that came up most was not licensing but ‘IP protection’. I’m very glad we’ve all come this far. And I hope we can continue and steer clear of absolute assertions a little longer.

Fourth, the cost of supporting CWT is minimal, especially for Firefox and Safari; Firefox has already built an eval version and both browsers support raw fonts through t2embed on Windows i.e. you effectively create a CWT under the covers before passing it to the embedding API. Allowing your code to read such resources – as opposed to only generating them internally - thus seems a hurdle so low that you would have to prove – or just believe ? - the benefit to most authors to be essentially zero in order to not support it.

It sounds like an unduly strong position to me, but it also seems to be where we are. Regardless, if CWT has no value and sees too little use, it’s a very small investment for you and we’ll all remain stuck waiting for WOFF to reach critical mass, leaving authors to wrangle with both WOFF and that format that is both evil DRM with rootstrings and pointless without them. Or CWT may in fact have enough value that by the time WOFF achieves sufficient penetration, font vendors and web authors will be sufficiently more comfortable with web fonts to enable the accelerated success of the latter.

Summary: with the potential downside being essentially as limited as your expectations, your opposition, while internally coherent, feels impractical. I admit I’m stumped.

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Thursday, October 22, 2009 2:11 PM
To: Tab Atkins Jr.
Cc: Chris Lilley; Sylvain Galineau; Levantovsky, Vladimir; John Hudson; www-font@w3.org
Subject: Re: Next step?

On Fri, Oct 23, 2009 at 9:22 AM, Tab Atkins Jr. <jackalmage@gmail.com<mailto:jackalmage@gmail.com>> wrote:
I don't see any reason to stand against CWT, honestly.

There is one, the point about deployability that I keep bringing up. I guess I'll bring it up again:

1) An EOT-Classic font with a rootstring is not a conforming CWT font, per the latest CWT draft. (Personally I and Sylvain think the draft could be changed to allow this, but other people, including Chris Lilley apparently, don't want to do this.)
2) Most font licenses will require authors to apply some kind of same-origin restriction
3) Given (1), the only way for authors to implement that restriction for IE users will be to implement Referer checking

That means deploying CWT will in most cases actually be harder than simply publishing a WOFF (or TTF) and EOT-Classic version of the same font. (And less reliable, due to Referer headers being stripped by firewalls.) This makes CWT pointless. Maybe I wouldn't *object* to it having an official spec, but I don't see why one would support it.

Sylvain characterizes this point as "a year ago EOT was unacceptable because of rootstrings and now we're being told it's useless without them." In a sense, I agree; this is a dilemma that cripples CWT.

(Note that even if (1) was changed so that fonts with rootstrings can be valid CWT, publishing fonts in multiple formats would still be just about as (in)convenient as publishing one CWT font with a rootstring; in your workflow, just replace the tool that sets the rootstring with a slightly more capable tool that spits out WOFF (or whatever) as well. So even if CWT changes to make issue (1) moot, I would still see very little value in it.)

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]