W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: Font license vs. conversion between font formats

From: karsten luecke <list@kltf.de>
Date: Tue, 7 Jul 2009 16:56:01 +0200 (MEST)
Message-Id: <200907071456.n67Eu1if021979@post.webmailer.de>
To: www-font@w3.org
Mr Rantalainen,

you addressed each point individually, but the problem is in the combination of these -- as I thought I had summarized in my other mail:

> (a) Users already have TTF/OTF fonts, licensed for print use, and these fonts work just as fine with @font-face.
> (b) "Downloadable fonts" are as easily downloadable as this term indicates.
> The combination of these two aspects turns every site which employs @font-face into a font filesharing host.

I cannot help thinking that you are trying to explain to me that there's nothing wrong about this.

As to your objections against EOT-only support, I have addressed them in earlier posts. In brief: As soon as browsers support TTF/OTF (whether exclusively or alongside other formats) we factually have font filesharing as a built-in special feature, kindly presented by Apple/Mozilla/Opera.

I know what font signing is, what it does and doesn't. But cannot remember having mention it in any of my posts.

> Am I correct that the problem is that such customers are not aware what they have bought? Or that they don't care? This cannot be fixed by an another file format.

A couple of type foundries, including the most popular ones like FontShop, have been quite explicit very early on as regards the licensing vs buying, and individuals spend a lot of time to tell designers so on forums like Typophile.
Support of a special, exclusive web-font format will be a stopper because: TTFs/OTFs won't work on the web just so. And (for example) EOTs won't work in the OS just so.

> If tools to convert from TTF/OTF file to the other font format ("web font") are available to anybody and converting the TTF/OTF file to such other format is the usual way of working with web fonts, how is this reminder of licensing terms the user is not aware of? [...]
> If tools to convert from TTF/OTF to any new format will be made widely available, then existing TTF/OTF files will be converted to that new format. And some part of those conversions will be unauthorized.

Tools would allow conversion and of course will not remain secret, but conversion is the tiny bit of extra effort that reminds people that they are possibly doing something wrong.
That there's always kids who feel challenged or people with criminal intend is one thing. For the general public, the fact that they cannot simply so install a web-font on their computer should be sufficient. We had the discussion about how "safe" things can be a few hundred posts ago, and think that nobody expects any miracles.
Below I attach a draft I wrote but didn't send because I thought all was said already.*

> OTF files can include bitmap glyphs if I haven't totally misunderstood. Do not distribute the actual font shaping data if you are not comfortable with anybody copying that data. Instead, pre-render those shapes as bitmaps and distribute a collection of those bitmaps as the "web font". Use deformed vector shapes if such data is always required by the OTF (I don't know). That would be the low-res font file directly comparable with low-res image.

The only reason for implementing @font-face is the desire to use REAL scalable fonts for web design. For anything less you may stick to images or sIFR or similar hack solutions.
(The last time I made pixel fonts was as a teenager twenty years ago, on my Atari 1040ST for Signum!3. And no, I have no intentions to travel back in time.)

Best wishes,

* The other one:


If browsers support raw TTF/OTF too, this would allow for a complete roundtrip and support for an additional format be a mere alibi. The current font filesharing situation would remain unchanged.


If browsers support only a single web-font "format"[1] like EOT[2], this format itself indicates: Font for web use only.
Optionally, it allows for rootstring info. (CORS being removed from the list of options as I see in Bert Bos' post.)
Optionally, it allows for compression.
Optionally, it allows for obfuscation. (Rejected? I don't remember.)
Optionally, web-specific machine-readable licensing info (?)
Optionally, user-friendly[3] licensing info (?)

[1] "Format" is a bit misleading. What constitutes an EOT font is a mere header/wrapper to a normal TTF/OTF.

[2] Whether EOT or EOT Lite or other, or whether this header/wrapper is external to the TTF/OTF font file or not, I leave open. I cannot say that I like the EOT header format but it's there.

[3] "User" means web designers first of all. End users, a website's audience, are not supposed to see the font. But if they happen to get hold of such a font, they may read the licensing and/or rootstring info and know: I am not supposed to use this.

Note that anything besides the "format"/wrapper itself is optional. This means that the web-font does NOT need to employ ANY of these options. The header-only should be pretty easy to create for those who offer free fonts. The header-only may suffices even for smaller foundries because OSes won't support this format -- the fact that this kind of use would require conversion says: Most likely illegal! And web designers who convert a free TTF/OTF font to EOT are by this very act reminded: Check the font's copyright/license info and origin so you are sure it is really a free font rather than a rip-off. (I assume that organizations like SIL would produce EOT fonts by themselves.)
It is this little (though only little) extra work that serves as reminder.
Received on Tuesday, 7 July 2009 14:57:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:02 GMT