an easy(?) font solution

I noticed a lot of heat and talking past
one another in the recent "Re: New work on
fonts..." thread.

I offer (revive) a straw-man proposal here that
I think can satisfy nearly all stakeholders in
the web font work, in a simple way:

1) Define a new file format, using MIME
   for a file with two sections.  One
   section is called "ABOUT" and the other
   section is called "PAYLOAD".  The content
   of each section may be of any media

2) The W3C font Recommendation should allow
   ("MAY") user agents to recognize any font
   format whatsoever, however:

3) The Recommendation should require ("MUST")
   that for each and every font format 
   handled, the user agent also supports that 
   format when wrapped in the MIME format.
   When a font is so wrapped, the user agent
   should ("SHOULD") prominently display to
   the user a link, or button which, when activated,
   displays the contents of the "ABOUT" section
   of the wrapped font.  The user agent may ("MAY")
   render using the font in the "PAYLOAD" section.

   When displaying the ABOUT section, user agents
   should treat the content, for security purposes,
   as if it had been loaded directly via the URL
   of the wrapped font file.

4) The Recommendation should choose one or more
   font formats which should ("SHOULD") be supported
   both in raw and MIME-wrapped files.

Period.  The end.  Full stop.

Now, what does this get everyone?

For those opposed to DRM (like me) this is 
satisfactory as DRA (digital rights assistance).
The "ABOUT" section of a wrapped font may convey
licensing information and the user has a convenient
way to see that information.   User agents are not
required to "refuse" to render with a font so
this is not a case of digital *restrictions* management.

For those who want their restricted license fonts
on the web but only in a so-called "obscured" format,
they can require that their fonts are only used on the
web while MIME-wrapped as I've described.   Users
will not, for example, be able to casually or accidentally
use these fonts directly in existing desktop programs,
for example.  Future desktop programs would likely come
to recognize the new font format but hopefully they
will preserve the ABOUT section and make it apparent 
to users.

For those who implement and maintain browsers, this
is an easy solution to implement and has the benefit 
of a adding useful functionality.

For those who care about "Libre Fonts" - fonts with
a very permissive, perhaps "copyleft" license to the
general public - the "ABOUT" mechanism is a means to
ensure that licensing information is conveyed along with
libre fonts.

Perhaps most interestingly of all, the very same
MIME format can also, in principle, be used for other
media types.  Linked images, CSS files, XSLT programs,
audio files, and so forth can all be similarly wrapped
and it is a simple matter to enhance user agents to 
recognize that wrapping and give users prominent access
to the "ABOUT" information.

Indeed, other applications (media players, word processors
and so forth) can eventually learn to handle the same
wrapper format.  As they do, they should, of course, 
preserve and give the user prominent access to the "ABOUT"

Most or all persistent concerns of stakeholders thus
solved, this would seem to be a good idea (though obviously
I'm naturally biased :-)

Note that nothing in this proposal *precludes*
the use of same-origin restrictions as a means of limiting
the propagation of font files.   The key point is that a 
W3C font recommendation should not need to mention same-origin
restrictions unless in non-normative language for informational

Note that a possible attraction of this proposal is
that it can unfold, longer term, into similar refinements
of W3C Recommendations regarding other media types.  Thus,
we have something useful to offer both users and purveyors
of audio files, video content, images, and so forth.

Finally note that a separate concern is then the possibility
of additional recommendations which standardize "what goes
in the ABOUT section".   In that area, if we were to discuss
it, I would want to talk about ccRel and RDFa.


Received on Friday, 26 June 2009 19:32:46 UTC