Re: Next step?

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

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

OK.

I tried to clarify this situation on this very list a while ago. All the
font vendors who contributed, which wasn't many, seemed to indicate that
their licenses do/will require authors to impose same-origin restrictions.
Earlier on in this process, many font vendors expressed support for EOT and
favourably mentioned its rootstring feature, which I also interpreted as a
desire for same-origin restrictions. Font vendors supporting WOFF are asking
for a same-origin restriction too.

If in fact there are major font vendors who don't (or won't) require
same-origin restrictions in their licenses, that would make CWT much more
useful. CWT's cause would be advanced if we could demonstrate that. Perhaps
I can ask you if Microsoft would permit use of its fonts on the Web without
same-origin restrictions?

 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 ?
>

I think a putative Fonts WG should not discuss bare TTF/OTF fonts at all. It
seems to me Microsoft has already ruled out implementing them, so the only
thing that would change that is market pressure, not a WG, so it would be
pointless for the WG to promote them as part of an interoperability solution
(I don't think the "2 of 4" approach has value).

I also think a putative Fonts WG should not mandate a particular same-origin
control mechanism. That would be controversial, restrictive and unnecessary.
What access control is required and how it should be enforced should be a
private contract between font vendors and Web authors. However, IMHO a Fonts
WG should recommend that browsers have the same "same-origin restriction by
default plus CORS" behaviour as Firefox, because that gives authors a useful
and convenient tool to fulfill their font license obligations.

 Third, the question is not whether you or I see value in it, but whether
> authors and therefore font vendors do.
>

That is absolutely true.


> 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 suspect Ascender and others have not fully appreciated that authors will
have to implement Referer checking, nor how problematic that will be.

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.

I've tried to elicit such statements in the past, without success.

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

Your argument isn't quite valid, since we support non-Windows platforms
where we don't deal with t2embed. But you're right that supporting CWT has a
cheap implementation cost. Then again, there's a maintenance cost that lasts
forever, plus similar costs to all other browsers and other tools, plus a
cost to authors of making format choice a bit more difficult. Not to mention
the cost of actually wrangling a CWT recommendation through a Fonts WG...

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]