How About Them Webfonts
August 30, 2009 (Updated: August 30, 2009)
You’d think that with the emergence of services like Kernest, Typekit et al, the state of webfonts—or Better Typography On the Web if you prefer that—would be rapidly improving? Yeah, you may want to think again. Even with better support of things like @font-face in browsers, and better text rendering engines for that matter, as well as much improved operative systems, there’s a side to webfonts where development is ... shall we say, a tad slow. This is an attempt at an overview of where things are at this point.

What are webfonts, really? What does the term mean? Well, if we want to be strict about it, it means fonts that can be used for HTML text and rendered by web browsers. That last part limits webfonts to .ttf (TrueType) and .otf (OpenType) font files because most browsers don’t render Postscript® fonts correctly, or at all. Postscript® font rendering is a platform (operating system) specific issue that has less to do with browsers. As far as we know, only Safari/Mac renders Postscript® fonts correctly. So, they’re out. And, to make it even pricklier, webfonts use in real life are limited to a set of “standard” fonts that are available for and can be assumed to exist on all major personal computer platforms. This is an old truth: you can basically only use 6-7 fonts safely on a webpage and expect them to appear correctly regardless of which system and browser you’re using to view the page. As with all old truths, this isn’t entirely true, since font rendering varies between platforms and browsers, but it’s close enough. So: less than 10 fonts can be said to be safe to use on a webpage.
What’s changed fairly recently is that demands for a typographically nicer web have become more vocal, following the enhancements of today’s computer (and handheld device) operating systems, and more browser makers have actually started to take notice. Up until 2006, only Internet Explorer had a good way of allowing for more ‘esoteric’ fonts for HTML text—the @font-face declaration. In 2007, Webkit, which powers Apple Safari, Google Chrome and more, included support for @font-face. Initially it was on an experimental level but today (2009) it’s quite stable. So, with a number of prolific browsers supporting @font-face, there’s increased pressure on the other browser makers (primarily Mozilla, which builds Firefox etc, and Opera) to include this support. And, as of Firefox 3.5 and development versions of Opera 10, they both comply with this pressure. Suddenly all major Windows and Mac browsers supports it—albeit on different quality levels. Pressure is now shifting towards the web standards organizations and type creators/vendors to solve the problem of distribution.
This photo was found on the Web, without attribution.
You can’t just use any font in your HTML text, not even with @font-face. Why? Because in order to use @font-face, you must put the actual font file on a web connected server, which in the eyes of the legal eagles constitutes a form of distribuition: you are making the font available to anyone, although “everyone” hasn’t got a license to use that font, which basically means you’re opening yourself up to litigation for license violation. The legal aspect is there to protect the type creator—to make sure that the original artist gets paid properly for the work. As a web designer or layperson, you might argue that this is up to the artist and the font vendor to work out between them. Lawyers will (presumably) counter that this @font-face thing is so new, no type vendor has really considered its implications on font licenses (that’s not entirely true, but for the sake of argument we pretend it is). The idea is that in order to protect the artist’s rights and ensure that no unlawful distribution is taking place when @font-face is used there must be a standard form or set of rules that all browsers with @font-face support must adhere to. The layperson pespective is: ”I’ve paid for this font set: I’m gonna use it. F*** u.”
Ok, maybe not so drastically worded, but you get the drift.
The question is on whom the responsibility of safeguarding the original artist’s copyright falls. If I put a font file, for which I have bought a user license, on a web server and that font file gets copied off the server by Wiley Coyote (who of course does not have a user license for the file) – am I the victim of intellectual theft? Or am I the intellectual thief? Type vendors will have it that by placing the file(s) on a public space, I am accountable when/if the file gets copied. Compare that scenario to an everyday one, in the world of web design: I buy a user license for a stock image, or video clip, to put on my site. Does the vendor automatically assume that because I intend to put it on a public site, I am accountable when/if the file gets copied by Wiley Coyote? How do we even know that Wiley Coyote, if he gets caught using the font or the stock image, actually got it from my site? In the case of stock images, most image vendors allows web usage in their standard license, as long as you don’t intend to resell the site as a template or similar. Type vendors, by comparison seem far more paranoid.
If webfonts are ever going to be a useful alternative then type vendors, in whatever shape and form, need to work out a licensing structure that is sane and which will allow type files to be used as the licensee sees fit (within reasonable constraints, such as no reselling, of course). At least, that’s how I see it.
Comments
This article hasn't been commented yet.

Add yours
* = required field
