Re: New work on fonts at W3C

On Thu, Jun 25, 2009 at 12:32 PM, Thomas Lord <lord@emf.net> wrote:

> On Thu, 2009-06-25 at 12:08 +1200, Robert O'Callahan wrote:
> > On Thu, Jun 25, 2009 at 11:41 AM, Thomas Lord <lord@emf.net> wrote:
> >         The bug is that it proposes a "Web-Specific Font Format".
> >
> >         There is not, nor can there logically be such a format.
> >         What is to stop libre applications from treating the new
> >         format as one among several native formats?
> >
> > I agree, there is nothing to prevent that. That doesn't bother me. If
> > it doesn't bother Ascender, then it's a non-issue.
>
> It's not a non-issue because the introduction
> of a new font format necessarily breaks interoperability
> among application programs.  Breaking interoperability
> among programs is nearly the antithesis of what W3C
> is about.  If the very rationale for a W3C recommendation
> is to introduce a new format for the sake of breaking
> interoperability, something has gone very badly wrong
> at W3C.


If you interpret Ascender's goal just a little charitably, it is to help
users avoid accidentally violating font licenses by blocking the trivial
"download font, install font" action, not specifically to hurt
interoperability. Blocking interoperability would be a futile goal since
it's trivial to change the application to restore it.

Plan, however, on libre desktop programs eventually
> being modified to treat the new "web only" format as
> an alternative native format, thus harming document
> exchange generally.


Trivially avoided on the sender side or fixed on the receiver side.

If variation in formats for the same domain is a critical problem for the
W3C, then you should direct your energy towards immediately shutting down
the XHTML2 WG, the WebCGM WG, and many others that I decline to remember.
Those are much more serious since they're not trivial variations.

>         4. Same-origin restrictions as described in the proposal
> >           are not CORS but are a DRM mechanism.
> >
> > I think Ascender clearly intended a default same-origin restriction
> > plus CORS to satisfy clause 4. I don't think that should be called
> > "DRM". All it does is let Web authors control over who can use their
> > resources via hotlinking.
>
> We are talking past one another, perhaps?
>
> A *server* may refuse to respond with a font file
> for whatever reasons the operator of the server
> chooses.  CORS captures a common case of those and
> makes it work more smoothly.


To be clear: what a same-origin restriction plus CORS actually does is
respond to the client's request with a resource *and* some
Web-author-provided metadata about which domains should be permitted to use
that resource. The client performs the permission checks. In the absence of
metadata only the resource's own domain is permitted to use the
resource. Delegating the actual permission check to the client enhances
privacy, because users do not need to reveal the source domain of the
request. I hope you agree that letting this happen on the client is a good
idea.

A *client* must never be required by Recommendation
> to refuse to render with a given font file based
> solely on the (potentially false) legal claims
> recorded as meta-data in that file.
>

Indeed. Ascender's proposal has nothing to do with that.

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]