W3C home > Mailing lists > Public > www-font@w3.org > April to June 2009

Re: restarting discussion

From: Thomas Lord <lord@emf.net>
Date: Mon, 29 Jun 2009 15:03:57 -0700
To: Håkon Wium Lie <howcome@opera.com>
Cc: www-font <www-font@w3.org>
Message-Id: <1246313037.7452.109.camel@dell-desktop.example.com>
On Mon, 2009-06-29 at 23:25 +0200, Håkon Wium Lie wrote:

> The only reason we're having this discussion is that some people find
> interoperability too dangerous. Xor-ing bits, adding compression, or
> adding metadata are equally disruptive for interoperability.

Yet among those choices, adding meta-data 
in the form of the wrapper I propose improves
the architecture of the web from a large number
of perspectives.  That is what distinguishes it
from the other two proposals.

However, you also have a counter proposal that
is not among the things for which I offered

>  > 3. Proposals to steamroll Microsoft are wrong. [...]

> I havn't heard anyone making this argument. The CSS Webfonts
> specification is format-agnostic today, and I think it should remain
> so in the future. 

I mistook *you* to earlier say "Recommend raw OT/TT and leave
it at that.   You must have really said what you say here:
leave it unspecified.

I have some sympathy for that point of view, but
only a little bit.   That trick played a realpolitik role
in the past but it isn't good for web architecture in
the long run.

On the one hand, you are in effect calling for a
"mod_font" plugin for Apache that autoconverts to 
EOT if it guesses the UA is IE.  On the other hand, 
you are leaving a big mess for anyone who wants to 
author cleanly archivable web content.

Trying to be, perhaps, inspirational I would say that
we are here now and this problem is ours to solve.
History will look back on what emerges from all
of this font work here and now and ask "did the
adults in the room step up and get things done
or did they allow petty squabbles to retard the 
development of W3C Recommendations."  We should be
the adults in the room, so to speak, and I think
we can be.

Everyone who has commented on it to me personally from the 
various font factions has expressed some warmth towards
by wrapper idea but skepticism it would ever actually
go through.  I think we should have more trust in what
can be accomplished here and go for that proposal.

>  > 4. Proposals for "root strings" are wrong.

> Agreed.

People still bring it up, now and again :-)

>  > What are we left with?
>  > 
>  > A "wrapper format" can be constructed which can 
>  > embed TT and OT, bundling such font files with 
>  > arbitrary, HTML-formatted meta-data for user 
>  > consumption.  By convention, font vendors can use
>  > that meta-data to include licensing information in 
>  > an accessible format, perhaps using ccREL and RDFa
>  > to make the licensing information machine readable.
> This is a slippery slope into DMCA-land. How will browser vendors that
> do not honor this meta-data be treated in the US legal system?

Not so and for a very specific reason:

There should be no normative language that requires
display of the meta-data ("SHOULD", not "MUST").  
There should be no rationale (only informative commentary)
that points out the utility of the feature for licensing

Free-form attached meta-data has many uses besides
licensing.  For example, the wrapper were applied to 
images and used widely on services such as Flickr it
could be used for RDFa markup of geographic tagging - 
tagging that persists even with copies of photos.
Here is an older description of the idea that sketches
a more general case:


What we have in the wrapper proposal is a way to
convey side-band data with any media file and a 
recommendation that such data SHOULD be presented 
to users who wish to see it.  By convention it can
be used for licensing data but by no means does the
presence or absence of the data or its presentation
comprise an enforcement mechanism or its circumvention.

It's just a useful feature that, hey what do you know,
is exactly the right thing for satisfying the stated 
goals of the font format hold-outs.

Received on Monday, 29 June 2009 22:17:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:31 UTC