RE: Next step?

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

>Discussion on this list was partly informed by Microsoft staff discussing under what conditions Microsoft might license ?>fonts for Web use. We were told that Microsoft wouldn't license fonts for Web use as bare TTF/OTF. So I'm asking whether >Microsoft would license fonts for Web use without a same-origin restriction under CWT as currently specified. 

Apologies, I was not part of such discussions so I can neither evaluate nor guess their context. Also not sure I follow the line or argument here, even if I understand the appeal of the obvious diversionary tactic; but as we don’t license Windows fonts for web use, I guess it's just another question you'll keep asking to support your position.

>I agree, however no-one is currently proposing that the Fonts WG consider them as a basis for an interoperable solution, so >I don't need to shoot them down :-).

I'm glad we agree they can't be the basis for a sound solution. That wasn't always Mozilla's apparent position.

>The problem is, if SOP is a requirement, and we don't have a convenient SOP mechanism that works with CWT on all high->market-share browsers that support CWT, then CWT isn't very useful. A mechanism doesn't need to be part of the spec --- >there could even be more than one --- but at least one does need to exist.

If SOP is an EULA requirement, WOFF will be equally pointless in a browser that doesn't implement SOP or equivalent for WOFF resources. Given that other browser vendors have implemented web font support without SOP, I'd think that should be a serious interop concern. I am thus puzzled that the SOP issue is so critical when CWT is the topic but a vague general statement about access control being up to private contracts is sufficient for WOFF ?

I also note that you are implicitly arguing that CWT would effectively work *better* for authors in Firefox than it does in IE thanks to built-in SOP vs. less convenient legacy mechanisms, much better support for CSS3 Fonts etc. And that competitive advantage makes it...less attractive for you to implement ? Uh.

>OK. I have tried to clarify in the past whether that means they're willing to drop the SOP requirement to make CWT work. >The clearest answer that I have been able to get says that Ascender, at least, is not.
>http://lists.w3.org/Archives/Public/www-font/2009JulSep/0867.html

>http://lists.w3.org/Archives/Public/www-font/2009JulSep/0986.html


Well, you're welcome to interpret mailing list posts as EULAs. All I have is font vendors who are aware of this issue pursuing the format nonetheless. I also have another header version that supports an origin control mechanism which works perfectly fine in legacy browsers and which CWT implementations would simply ignore. You may be familiar with that since you suggested it. So if SOP were a blocking issue, we already have a working solution. 

But if SOP is so critical to the viability of a web font format, shouldn't it be specified as a requirement for web fonts in general ? Why is it an issue for CWT only ? Surely we don't want to risk the release a 'pointless' implementation of WOFF, do we ?

>Re-reading my message above, I feel that is an unfair characterization. I think my probing on this issue is worthwhile, >given you yourself wrote:

< < So whether this can work may come down to the license language. If it requires 
< < same-origin check then the installed base benefit is hugely offset.

Nice job extracting the unfinished thought and quoting it out of context :) The subthread this is extracted from describes my choice of header version, specifically one that does not include rootstrings (a relevant starting point is here http://lists.w3.org/Archives/Public/www-font/2009JulSep/0862.html). If that remained the format *and* EULAs do require same-origin enforcement then yes, *this* specific iteration of the format will need revision.

Which I also explicitly agreed to here (http://lists.w3.org/Archives/Public/www-font/2009JulSep/0864.html):

"If licenses do require that, we’ll revisit. Ascender made the proposal and does not require them." (Once again, Ascender released tooling that produced CWT files with no rootstring space; then revved it, well after you made your point; repeatedly)

But given that you're quite comfortable with the 2.1+ header versions that include rootstring space, your only requirement is that we use those instead of 2.0. I'm fine with that. My primary goal with choosing 2.0 was to keep the first iteration as simple as it could be and skirt around the Monty Python realm of 'Rootstrings are DRM!'. I don't mind using 2.1 or 2.2. Same thing to me, really. 

Managing rootstrings are not as kind on authors as SOP - it'll require tools, for one - but if it's at least better than referer checking, the judgment call on the cost/benefit is, once again, up to said authors.

So, assuming CWT has rootstring space, is still still 'pointless' ?

Received on Friday, 23 October 2009 06:27:14 UTC