Re: New work on fonts at W3C

I'll try to respond to all of you with this mail.

    Firstly, I fully understand that secure font is a myth. When it's 
possible for a browser to
get an information, it's also possible for any program to do so, and then 
extract the data
and make them free.

But it'll be clear that it's illegal (downloading a file and using it 'as 
it' doesn't seems wrong
for many people, while unencode a file and 'hack' immediately makes the 
problem clear
and inaccessible for people having less knownlegde in informatica).

This is thus not a 'no more problem' solution, but it's a part of solution. 
I ever prefer an half
solution than no solution at all.

    Secondly, I agree with those who say 'Why a format especially for fonts 
? Why should we
not create a embeding format allowing to work with all kind of files ?'. I 
would like to say it's
the best solution, but it have some problems, too. Firstly, it will not meet 
all concerns because
it'll be 'byte-based' securisation, and not 'data-based' securisation, which 
is not really the
same as it's easier to decode a simple byte format than a whole format.

But if this idea seems acceptable to the UA's builders, I think it could be 
a good solution, too.

The last thing we need in implementing new format is end-less controversial 


From: "Dave Crossland" <>
Sent: Tuesday, June 16, 2009 1:20 PM
To: "François REMY" <>
Cc: "Mikko Rantalainen" <>; <>; 
"Thomas Lord" <>
Subject: Re: New work on fonts at W3C

> 2009/6/16 François REMY <>:
>>>> Again, you don't look at 'Why do the copyrighters say we can't use
>>>> the font on the web'... Because "there's no secured way to transmit it"
>>>> seems to be the key word of their arguments...
> There cannot possibly be a secured way to transmit fonts, video,
> music, or any digital information. Its like trying to make water not
> wet.
> However, the Ascender proposal DOES NOT try to securely transmit fonts.
> Tom Lord wrote a small paper about the proposal at
> which I append:
> - - - 8< - - -
> 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." -

Received on Tuesday, 16 June 2009 13:45:20 UTC