Re: Next step?

On Fri, Oct 23, 2009 at 2:54 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

> If you refer to the fonts that come with Windows, they are not licensed for
> web use. Same-origin policy or lack thereof has nothing to do with it.
>

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. I understand that
you probably can't answer that immediately, but an answer would help
everyone evaluate the value of CWT.

That was not the point. If both font vendor support *and* same-origin policy
> are essential to a successful web font format then two out of three of the
> current raw-font implementations are, by your own standard, even more
> useless than CWT. And will remain so whether Microsoft supports TTF or not.
> They should thus be so characterized and challenged.
>

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 :-).

It certainly should; if lacking SOP makes a format useless then achieving
> interoperability requires same-origin policy by default whatever the on-disk
> format. If lack of SOP makes CWT pointless then surely WOFF would be equally
> pointless on those browsers that do not apply SOP to WOFF resources. Thus
> WOFF's interoperable success depends on SOP.
>

Yes, it depends on there being some convenient SOP mechanism available in
browsers that support WOFF.

I agree that 'what access control is required and how it should be enforced
> should be a private contract between font vendors and web authors'. And that
> is exactly how I see the CWT SOP issue you keep raising. The statement
> applies just the same.
>

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 authors are willing to step up and say "yes, we understand we have to
> implement Referer checking, and that's OK, it's >easier for us than the
> alternative of serving both WOFF and EOT Classic", then that would be good
> for CWT. If Ascender is >willing to step up and say "yes, it's OK to serve
> our fonts without imposing same-origin restrictions", that would also be
> >good for CWT.
>
>
> As you said so well earlier, 'what access control mechanism is required and
> how it should be enforced should be private contract between font vendors
> and web authors'. In the absence of such contracts, all I have is the strong
> public and private statements of Ascender, Monotype and others asserting
> they want this to work.
>

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

Correction: you have been unsuccessful in getting a font vendor to agree
> that this issue made CWT pointless.


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.

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]