The web design field has been all atwitter with talk of a future where web fonts are actually available. It’s like the flying car of web design, and it may actually arrive in a useful form before we know it. Even my good friend Samantha, who’s generally happy trying to do as much as possible with the choices we already have on the web, got giddy at the notion of having Mrs. Eaves available to her as a web designer.
The recent optimism centers around three recent developments: @font-face support in Firefox 3.5 and Safari, the .webfont proposal by Tal Leming and Erik van Blokland, and the in-private-beta TypeKit service led by Jeff Veen.
Long story short (as I understand it), type foundries don’t like @font-face, because it basically makes it easy to download fonts from any website that uses it. For some reason, the foundries seem to be getting behind the other two proposals.
From my chair, though, it doesn’t look like the TypeKit and .webfont proposals offer anything that really should satisfy the foundries.
Here’s the simplest way I can explain the proposal:
- Take a font you want to use, probably in .otf format.
- Make up a little XML file that has some metadata about the font, including some fields that define permissions. This is all in plain text.
- Zip the two files into one, and name it .webfont.
That’s nice and all, but that’s trivial to make, and offers the foundries no protection of any sort. It simply obscures (barely) the permission table in a zip file.
If I wanted to use my favorite typeface, it would take me no more than three minutes to make a .webfont file for myself, and I’d still be able to download others’ .webfont files from their websites and take their fonts, were I a nefarious type of person.
There are lots of foundries supporting .webfont. I suspect that most don’t really understand the proposal, and think that since it was created by two folks from inside the industry, it must be everything they need.
However, it’s trivial to go ahead and download the font from TypeKit anyway. Base64 encoding, the method TypeKit uses to obfuscate and embed fonts, is incredibly simple, and by simply pasting the embedded font (from, say, Firebug) into a decoder like this one, you’ll have an .otf ready to use on your local system.
How trivial? Here’s how long it took me:
Don’t get me wrong: TypeKit does offer a new and very interesting business model for type foundries, but it doesn’t offer anything in the sense of real security to foundries. As they say: security through obscurity is no security at all.
If it were just the business and licensing model that foundries were going after, they would already be offering very expensive web licenses for fonts, wouldn’t they? They can do that themselves, without a middle-man.
So What’s the Issue?
So if foundries don’t like plain @font-face because of the potential for downloading fonts, why do they seem to like .webfont and TypeKit? Is it:
- That foundries really just want some form of barrier between the font and the user, and they expect users to heed this boundary, even if it’s only a small hurdle?
- Foundries just don’t like the idea of an .otf freely floating around?
- Foundries don’t really understand the proposals at all, and think they provide some level of security when they in fact do not?
I’m one of the folks who thinks that @font-face is good enough in itself, since we’ve gotten this far with raw embedding of things like images, and the stock photo industry clearly survived and continues to do reasonably well.
But I fear that although everyone is beginning to feel the momentum and get hopeful, foundries will soon come to find that these proposals offer them relatively little (TypeKit’s rental model excluded) that they don’t already have, and they’ll pull their support just as quickly.
So if downloading an .otf isn’t really what we’re trying to solve, why aren’t more foundries offering web licenses right now? Why support the .webfont proposal? Why look to TypeKit as the key to unlocking the puzzle? Is a non-proprietary EOT-like format really the answer we should be looking to?
What are we really trying to solve?