Thoughts on Ascender's 2009 proposal

by Tom Lord, 16th June 2009

Executive Summary

Ascender's 2009 proposal for web fonts is a big improvement on the Microsoft-Adobe proposal that "Embedded Open Type" become a web standard. But the proposal could be better, and more likely to get traction, if it also served the needs of other media developers.


Most of the papers on this site were written in 2009, when some people feared that the W3C was going to rush to standardize a form of DRM for web fonts; specifically, EOT's requirements that root strings be enforced by web browsers.

Recently Bill Davis from Ascender has published a new proposal for web fonts. I kinda like it, but I would like to see some improvements and generalizations before I can say that I really support it:

The proposal suggests that consensus might be formed around a standard “web font” file format that:

  1. is distinct from legacy formats used for restricted-license fonts
  2. supports subsets and patent-free compression
  3. conveys copyright, patent, and other licensing information in a way that client applications are encouraged to use to keep users fully informed about the content

Stated abstractly like that: I agree with all of those goals.

The proposal further suggests that some non-free fonts might be licensed for web use under terms that require licensees to serve those fonts on the web only using existing “same-origin” restriction mechanisms. Some, in comments above, have questioned how the customers will feel about this. I think it is a fine idea in principle and a good enough idea if the customers in question are willing to work with that.

Here is where the proposal loses me a bit:

The proposal is for a new font format specifically. I think that is not quite right.

The same concerns motivating this proposal for a new font format are shared by makers of non-free image files, video files, audio files, text files, and so forth. That is the first key observation.

The second key observation is that a single solution for all media types is quite viable: a “wrapper file format” that can convey licensing information and, by virtue of changing the byte-stream - differ from legacy formats. That is, we can take existing font formats of all types and wrap them in a format that adds such things as licensing information. The wrapper would be slightly redundant with some features of existing font formats but not by much.

A wrapper format like that can in principle apply to any linked (or “embedded”, if that is really a concept) resource. There is nothing “font specific” about it. Clients such as browsers can be modified to recognize and unpack such a wrapper in a generic way - not in font-specific code. And thus we solve similar problems for all media types, all at once.

I think that going that route is actually the best way to persuade not only restricted-license font vendors but also browser makers to adopt. The way to encourage that adoption is to reach out to people interested in other media types (such as music and video) and get them interested as well. For browser implementors, it is a small change to handle this new wrapper format around any media type and to begin to add features to, for example, give users convenient access to licensing information for “embedded” media.

It is difficult (probably impossible) for W3C to accept in one gulp the idea of a wrapper format across all media types - that’s a big step for humankind, not a baby step. Yet it is practical to advertise the intent of getting to that point while initially promoting a generic wrapper as a solution specifically for the immediate problem of fonts.

A third key point is that the benefits of such wrappers are not unique to distributors of “non-free” media files. Those of us who produce libre content are also often concerned to see that such things as licensing meta-data is conveyed with the work and that users are informed of that meta-data. A generic wrapper format will help libre causes as much as it will help restricted-licensing interests. Thus, it seems a good centrist position, to me.

I have sketched a proposal for how such a wrapper format might work in the others essays on this site, "MAME: Multimedia Attached Metadata Expression " and "Resource Meta-data and User Notices."