That Vexed Issue of Fonts

Clients are often very specific about the fonts they want to see on their website. Unfortunately, there are technical and financial issues that need to be taken into consideration.

A web page is not like a pre-formatted image. What is actually transmitted to a web browser (eg. Internet Explorer, Firefox, etc) running on a client computer (ie. where the website is viewed) is a stream of numbers representing the alphabetic or numeric characters to be displayed along with a set of codes to tell the browser how to format those characters, including which font should be used. Unfortunately, if the specified font is not actually installed on the client computer, it cannot be used.

There are essentially three ways to deal with this problem, each with its pros and cons.

Web-Safe Fonts

There are a number of fonts which are considered "safe" to specify because they will normally have been installed on any and all client computers. In order to accommodate the possibility of a missing font, alternatives can be specified. The browser will try to locate fonts in the given order, and use the first it finds. This process is know as "degrading" (a word that some find very appropriate). So, for example, you might specify the Arial font, with the Helvetica font if Arial is not found. In case neither is available, it is always wise to specify serif, sans-serif or cursive so that the browser can at least try to show something vaguely appropriate. Unfortunately, even if the first font is available, it may not look exactly as expected on different computers and browsers due to variations in rendering. The main problem with this solution is that the number of available fonts is very limited and, whilst they are all very usable, this does not give you very much variety.

• Pros: low bandwidth overhead; technically simple to implement.
• Cons: very little variety of fonts; visually, the results are somewhat unpredictable.

Images of Text

For a long time, the only practical, cross-browser method for displaying fancy fonts was to produce images of the required text. Whilst this is by its nature a bit of a hack, it works surprisingly well. It does mean that you can determine exactly how the text will look and it will be the same on every computer and every browser. Its main downside is lack of flexibility; images are much harder to edit than text. If you are using a content management system, a very sophisticated piece of code is required to be able to generate images on the fly as text is changed. But there is a more insidious problem: images of script cannot be read by screen readers (for the blind or partially sighted) and, perhaps more importantly for the majority, they cannot be understood by search engine spiders. Because of this, text in images simply does not appear on your page for these programs. There is a workaround which is to hide real text behind the images, but this just keeps getting clunkier. You can't do this for large quantities of text. I have used it for headings in the past and that is all it is good for.

• Pros: you determine exactly how the piece of text will look on every computer and every browser.
• Cons: decreased speed/increased bandwidth usage; not practical for anything more than headings and menus.

CSS3 @Font-Face

The font-face method is generally considered to be the way forward and is included in the CSS3 specification. Font-face allows you to supply the required font in a file on the web server and transmit it to the web browser on the client machine. In theory, at least, this means that you can display exactly the font you want. It is not exactly new to CSS3, having been available in Internet Explorer since version 5. However, typically of Microsoft, it required fonts in a proprietary format which is incompatible with other browsers. Now, with more modern browsers, website designers can use any licensed TrueType or OpenType font in their pages and the method is becoming truly usable in the real world.

Inevitably, there are problems with this approach. The first is that, despite supplying the actual font required to the client machine, there can still be visual differences in its appearance. The font may simply be rendered differently, with different degrees of boldness or italicisation. XP's font rendering is generally pretty grim even with ClearType enabled. Nevertheless, at least the variation is usually minor and you have the font you wanted.

The main pitfall is one of copyright and therefore cost. Most fonts are commercial. If you are transmitting a font to every client computer that is viewing your website, then you are distributing that font and you need to buy an appropriate licence. Most font sellers can supply a font-face licence these days, but it does not come cheap (anything from around £25 to £350). The solution is to use a font with an open licence (effectively free) of which there is an increasing number these days. As a supporter of Open Source and GNU General Public Licensing, I approve of this approach.

• Pros: you get the font you want wherever you want it on your website without limitation.
• Cons: potentially expensive if commercial fonts used; results are not completely predictable due to rendering differences; some bandwidth considerations exist transmitting the font files.

Conclusion

You can't always have the font you want. And even if you can, there are complications. Each of these solutions has its merits; it is a case of using the right one in the right place. The important thing to understand is that web pages are not like pdf documents and a great deal of care has to be taken to make sure that the design appears as intended across all systems and browsers.