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

Re: New work on fonts at W3C

From: Thomas Lord <lord@emf.net>
Date: Wed, 24 Jun 2009 17:32:41 -0700
To: www-style@w3.org
Cc: Robert O'Callahan <robert@ocallahan.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>
Message-Id: <1245889961.6569.172.camel@dell-desktop.example.com>
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.

>         3. Gratuitous table renames suffer the same problem as
>           problem (2) - it seems that point (3) of their proposal
>           is just a specific case of point (2).

> Indeed. It's about the minimal obfuscation we could have (avoiding
> EOT's completely unnecessary checksums). The impact on browser users
> is zero, the impact on Web authors and browser developers is minimal
> --- it doesn't seem like a problem to support it. Don't forget that we
> will definitely be supporting normal TT/OT font files, so people who
> don't want to deal with the obfuscation won't have to.

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.

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

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.


> Really, that's all. It does not govern copying or usage, and is not
> aware of licensing. Web authors may find it a useful tool to help
> ensure they comply with font licenses. Technically it's equivalent to
> Referer checking, except it's more reliable and much more convenient
> for authors.
> 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 Friday, 26 June 2009 00:31:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC