It seems hardly a week goes by lately without some interesting new development in online typography. For years there has been a constant grumble from many that the web needs more typefaces available to designers to create great online typography, and there’s been a consistent, and entirely correct (but perhaps rather hardline) response from others that great typography doesn’t come from having lots of typefaces. Perhaps you can tell from that which side I come down on, and yes, it is rather hardline, and I freely and happily admit that as a response to the problem it rather misses the point.
The FontBook. Photo courtesy of Stephen Coles.
You can, of course, create great typography using only one or two typefaces for your entire working career as a designer. I’ve met a few designers who seem to want to do just that, and indeed, I heard a story of a creative director so obsessed with Bembo that he wouldn’t allow any other face to be used on anything, so that none of the designers who worked with him could ever bear to use it ever again. Most of us, like those very designers, would quite reasonably get bored to death with using the same faces all the time. No matter how beautiful, how perfect, how utterly balanced the typeface was, you can have too much of a good thing, eventually - and if the faces you have available are, shall we say, of mixed quality, then you can feel rather stifled, rather quickly.
This is the situation we’re in now. We’ve had the ‘Web Core Fonts’ for seemingly forever, and we’re fed up with them. There are so many excellent screen faces out there, and we want to use them. But how? I won’t seek to repeat some excellent articles on the current state of play (I suggest you read this article on ilovetypography.com), but I fancied including some of the context, the history of how we’ve used non-core faces online until now, and my own opinions one where it’s all going.
Making images of text yourself
Slow and tedious, not very accessible and relatively inflexible, this isn’t really a solution at all, but is certainly the most reliable way of presenting text in your own typeface online. It’s getting less common thanks to the growth of various other methods, but still hangs around for obvious reasons: You can fine-tune everything - the kerning, ligatures, alternates, all sorts of effects, it’s all under your control. Sounds great, until you have to change the text. Then you have to fine tune it all again, save off all the images again, upload all the images again, then try and work out why you’ve got a broken image on your site again until you remember you changed the filename when you were in a hurry that time and you forgot about it…. So, it’s good for things you don’t change often.
Making images of text automatically
For many years this seemed a golden solution, lit by a kind of heavenly light from within, choirs of angels and all that: all the benefits of making images yourself, but without all the fuss and effort! Joy! Well, not quite. There are various methods for creating the images automatically, from using a desktop application like Fireworks to online PHP libraries (and similar), and they all have their limitations. The first, of course, is that you’re creating the images automatically so you don’t have quite so much control over how the type looks, and most of the PHP libraries I’ve seen over the years don’t support kerning, which is a bit of a showstopper if you care about such things, and if you don’t care, why are you doing this anyway? Also, like creating the images yourself, you still end up with folders full of loads of tiny files, and your pages will be slower as a result of the browser having to request each of those files individually. Not ideal in other words.
Live replacement with Flash or SVG
And here we find some very clever solutions, the most widespread being Scalable Inman Flash Replacement, or sIFR (yes, with a small ‘s’). This technique uses a combination of Javascript and CSS to replace text with a Flash movie showing that same text but instead using a font embedded within the movie. When used for small amounts of text, such as a couple of headlines on your page here and there, it can work very well, hence its popularity.
There are some benefits to using sIFR: You can choose a subset of characters to include, which can keep the filesize of the Flash movie fairly low; and as it’s not the actual font file you’re embedding, it adds a barrier of security to people who might want to rip it off (how high a barrier that is remains debatable), and, as with all Flash movies, you can block the file from being reimported back into the Flash editor (again, with debatable efficacy).
There are also some real problems with using sIFR. The main one is speed. If you use it for any amount of text you’ll notice quite a lag while the text is replaced and the Flash movies rendered. Using it for a lot of text, such as the body of an article, and you will most likely notice a significant performance hit on your browser, or a crash. It can also be blocked by ad-blocking software - I use Click2Flash on Safari and I haven’t set it to allow (or disallow) all sIFR, just in case, so I often see placeholders all over pages. The other main problem, and it doesn’t particularly affect users, is that it is a fairly brittle, poorly documented and really annoyingly bitty solution - it’s an absolute pain in the arse to set up, basically.
Another option very much worthy of mention (and I’m not going to cover every single one) is Cufón. This works by using Fontforge to convert a TrueType or OpenType font file to, essentially, a Javascript file. Naturally there’s a little bit more to it, which you can read on the Github page should you wish. The setup is extraordinarily simple, the rendering of the type is extremely fast, even when used on a lot of text, and works with straighforward CSS rules. It’s not absolutely perfect, as there are a few issues with Internet Explorer (no surprises there) and there are some concerns that the font file can be reassembled from the Cufón file - though the technological barrier to that is enough to defeat most people.
Of which questions of licensing and piracy leads nicely onto…
Directly linking to the font file on your server
Basically, you upload a font file to your server and link to it on your web page or stylesheet and when someone views your page, the font gets downloaded, interpreted, and your text is then displayed using it. Simple. Well, kind of. Since version 5, Internet Explorer has supported the font-face rule, allowing you to link to a proprietary file format, Embedded OpenType (EOT), which allows for subsetting (like sIFR does), proprietary compression and a simple form of DRM to limit the file to use on certain domains. This format was never supported by other browser makers, and foundries never explicitly allowed for the use of their typefaces in this format, so it never took off. In many circles, it was viewed as a Bad Thing, another attempt by Microsoft to foist proprietary technologies onto the web, and further evidence of how evil they were. Though perhaps if you subscribe to that view you might want to look up who commissioned the Core Web Fonts in the first place. Verdana and Georgia are bloody great (on screen).
So, we went many years with a partial solution available, but never used. Recently, however, a couple of new proposals have emerged. One is the .webfont proposal by Tal Leming and Erik van Blokland, which seeks to create a format-independent XML wrapper for fonts, with compression for the font data itself. The XML wrapper contains various data, including allowed URLs, the license and origin, and anything else the foundry wants to put in there.
Essentially, the XML wrapper in .webfont is a form of DRM. It contains the license, and if you ignore it and rip off the font file, then you’re open to prosecution. It’s true Digital Rights Management rather than Digital Rights Enforcement.
Interestingly, there isn’t any restrictive DRM (Digital Rights Management), obfuscation or encryption in the format. DRM is a tricky one. I’ve never been entirely against it as a concept, but more against the appallingly greedy, grasping, restrictive, anti-consumer, anti-liberty, anti-fair-use moneygrabbing application of it the music industry employed. I don’t rip off music or movies, and yet my use of my media is limited by these restrictions - it’s insane, so I can see why the idea of adding any form of DRM to font files is now beyond the pale, even though with typefaces it could, arguably, be justified. The only option is to keep educating people that they’re not free, that they take time to design and perfect, and that yes, if caught, you can be prosecuted. Kids and enthusiasts building massive font collections they’ll never use are one thing, but professionals should, and must, know better.
Anyway, I digress. The other proposal getting attention is EOT Lite. This is a resurrection of Microsoft’s original EOT format, but with the DRM-like restrictions and patented compression methods removed. This makes it a reasonably credible addition to the options available as it is already supported by a major browser, but whether it can overcome the poor start (and worse publicity) EOT had is doubtful. While .webfont has the support of most of the larger and important foundries, a couple of big foundries have backed EOT Lite. Well, that is until halfway through me writing this article when Typegirl tweeted that Adobe are backing the .webfont proposal. We shall see, and of course there’s no problem with a foundry supporting multiple solutions. Certainly Linotype have already added EOT to their EULA, which is great news as it signals that one of the biggest barriers to using different faces online, licensing for web use, is actually now being overcome.
And, with that other nice link on licensing, we move to…
Subscription: Using the font file on someone else’s server
Typekit’s list of typefaces. Cropped from this screenshot. Yes, I recoloured it too.
Now this is really exciting, and has implications for font licensing for the desktop as well as online. You pay a subscription, and you get access to a variety of typefaces you can use on your site. With Typekit, the process is handled using Javascript to enable the font in the browser, which you then refer to in your stylesheet using standard CSS rules. Other services, whether from foundries, resellers or dedicated service providers, will no doubt develop their own systems, but I imagine they’re be all along similar lines. The question for me is one of performance. I don’t know about you, but I’ve occasionally been left waiting for a page to load while the browser waits for a response from, say, google-analytics.com - there’s no question Google’s main analytics web servers are down (not this often anyway), but just that sometimes this happens on the web. How would this affect a page using Typekit? Is there any option for local server caching for example? If so, how would that be handled?
I’ve often thought that a subscription model for typefaces would be ideal for agencies, designers and printers - people who need access at short notice, and for short periods to a wide range of faces. At the moment, there’s a lot of dodgy emailing of font files about, and you can bet that no matter how scrupulous at licensing everyone concerned may be, that a lot of these font files stay installed and end up being used beyond their licenses. Foundries, and for agencies, etc. concerned about their liabilities to prosecution (and of course, for doing the right thing) would welcome a system that allows you to get access to a face for a week, or a month, or whatever, and, most importantly, to change what they have access to whenever they need to. To make it work you’d have to be paying less per font (or even per face) than for a full license, but for the foundries this would represent a consistent income, rather than no income at all. It’s a thought. I’d certainly use it.
The Future
The whole push to develop practical ways using typefaces online is inevitable given how many applications are now moving into ‘the cloud’. We’ve word processors and photo editing applications online now, and it’ll only be a matter of time before professional creative tools go online too. We want to be able to access our documents from anywhere, and for them to use the same faces as we created them with, and for these documents, the web core fonts aren’t going to do the job.
With the online subscription model, there is a cautionary note to keep in mind - you don’t have control over what’s available. As Kindle users who thought they’d bought Orwell’s 1984 recently found out, if your service provider doesn’t want you to have it anymore, you have no say in the matter. At least if you have the font file on your own machine or your own server, you can keep using it even if the company you bought it from no longer wants to sell it. We’ll no doubt see both honourable and dis-honourable business practices, some scandals, some interesting legal actions, and probably new primary legislation on the matter, but until then, as ever, caveat emptor.
