W3C home > Mailing lists > Public > www-style@w3.org > June 2009

Re: New work on fonts at W3C

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 25 Jun 2009 14:27:11 +1200
Message-ID: <11e306600906241927q4152433eoa1b087244af09fde@mail.gmail.com>
To: Thomas Lord <lord@emf.net>
Cc: www-style@w3.org, Aryeh Gregor <Simetrical+w3c@gmail.com>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, Brad Kemper <brad.kemper@gmail.com>, Jonathan Kew <jonathan@jfkew.plus.com>
On Thu, Jun 25, 2009 at 1:50 PM, Thomas Lord <lord@emf.net> wrote:

> On Thu, 2009-06-25 at 13:13 +1200, Robert O'Callahan wrote:
> >  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.
>
> I think that the impersonal formal voice of a
> standard has to assume that that "blocking" is never
> a legitimate rationale.


I don't agree at all. Preventing certain things from working so that it's
harder people to make mistakes motivates many spec design decisions.

Here is what I mean:  If the new format catches on
> enough libre applications will adopt it eagerly while
> other applications might not out of some misplaced sense
> of solidarity.  MS Office might refuse it, for example.
> So someone using OpenOffice encounters new document exchange
> problems with someone using MS Office.


The OpenOffice developers could easily forsee this problem and decline to
support embedding of the obfuscated format. Or, they could automatically
deobfuscate the font at the time it's embedded. Or, they could deobfuscate
it when the document is exported to MS Office format. These are all trivial
to implement. Note that there are already lots of font formats that cannot
be transported interoperably across platforms, for which no easy solution
exists.

> 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.
>
> I really don't follow you there.


The W3C has a long track record of developing specs for different formats in
the same domain. And generally those formats are much less interconvertible
than what we're talking about here.

> 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.
> >
> I don't think that that's an accurate description, quite.
>

Then enlighten me.

> 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
>
> It doesn't so delegate, not quite.  It allows the client to
> help streamline a permission check that the server can
> imperfectly enforce.


I don't understand your distinction. It actually does delegate, since if the
client wanted to it could just always permit access. That's another reason
to favour client-side checks (for all sorts of things): the end user has
ultimate control.

> 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.
>
> The introduction of pre-flight checks is a good idea, if that's
> what you mean.


Pre-flight checks are not relevant here. They are only required when the
request itself could be dangerous.

>         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.
>
> One of their "five aspects" suggests otherwise.
>

You mean the last one, "License information"? It explicitly says

> Enforcement would be the responsibility of the font vendor and not the
> browser or authoring tool,
>

What are you seeing that I'm not?

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]
Received on Thursday, 25 June 2009 02:27:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT