Fonts, Web Design, and the Holy Grail

by
Todd L'Herrou

At some time or another, most web designers struggle over the issue of how to display a specific font on a website. In general, for website text to display in a specific font face in a client browser, the client computer MUST have that font installed. Site visitors who do not have it installed will not be able to see the text in that face. Yet, good design (and paying clients) often require that a specific font be used.

There's no easy solution to this issue. However, there are a number of approaches that can be taken to accomplish the goal. Each of these possible solutions come with trade-offs.

History:
Originally, HyperText Markup Language (HTML) provided only simple means to manage the presentational aspects of information (which was primarily text - words and numbers). Words could be marked as bold, italicized, or underlined, and GIF or JPG images could be presented inline with the text. Stylizing the look of the content was an afterthought. Over time, as the HTML specifications progressed, browsers became more sophisticated, and designers demanded more capability, this evolved. Initially fonts were selected by the browser. Eventually, through the use of the <FONT> tag and then CSS specification of font face, the HTML coder was allowed to suggest fonts that could be used, if available on the local client computer.

In parallel development, the <TABLE> tag (and related <TH> and <TD> tags), originally intended only as a means of presenting tabular data, were co-opted by designers as a means of positioning of various elements on the page. This was important because it allowed designers to exactly position elements over the entire screen, and use images as both foreground and background for table cells. A common practice which evolved from the use of these tags was the creating of images of text, in which the designer would create the text in the desired font in their graphics program, then save it as a GIF or JPG file, and position it within the design using tables. While positioning of the elements has changed with the advent of CSS, this is still the most common method of displaying a specific font in a website.

Embedded fonts
While images of text was a useful capability, there were drawbacks (we'll talk more about those in a bit). The obvious goal, for web designers, was to find a means to have the viewer see the website they designed, as they designed it, fonts and all, without those drawbacks. Bitstream, a digital font foundry and software company, created the TrueDoc specification (an open specification) for embedding fonts (Portable Font Resources, or PFRs, more specifically) in software, including web browsers. Bitstream worked with Netscape from 1994 to 1999, and Netscape licensed their TrueDoc technology (renamed Bitstream Webfont dynamic font display) for Netscape Communicator. However, Netscape ended the collaboration with Bitstream with Netscape Communicator 6. Bitstream continued to offer a free font conversion tool for a number of years, allowing designers to convert TTF fonts to PFRs for use in websites.

Following the Bitstream lead, but determined to do things their own way, Microsoft created Web Embedding Fonts Tool (WEFT) (http://www.microsoft.com/typography/Web/embedding/weft3/default.htm). While promising, Microsoft's embedding technology was limited to Internet Explorer only, and was never adopted by other browsers.

Complicating both efforts was the legal issues revolving around embedding of fonts. Fonts fall in a odd area of the copyright law. Without going into a great deal of detail, most of the copyright protection for digital fonts actually relies on the fact that they are "software", rather than on unique features of the letter shapes. Embedding of fonts in a website can be seen as freely distributing software that is covered by copyright protection - and permission for free distribution of any copyright commercial software is not commonly seen in any licensing agreement.

Faced with this issue, and the failure of either Bitstream's PFR or Microsoft's WEFT to emerge as an defacto standard across browsers, Bitstream withdrew the free tools it had made available. Development of WEFT stalled some years ago, Microsoft no longer formally supports WEFT, and has transferred their WEFT user forums to Fontlab, a software company that makes digital font design software.


Where are we now?



As I've discussed, each of the prior attempts at created means of embedding fonts have largely withered away. While it may still be possible to find PFR files for some fonts on the web (as well as Bitstream's now-withdrawn font conversion tools), licensing issues still remain, and the technology was never incorporated into Internet Explorer. An ActiveX control was produced, which allows IE browsers to display PFR fonts, but this requires additional coding and that the site visitor's browser have Javacript and ActiveX enabled.

WEFT, as a Microsoft proprietary solution, was never adopted by browsers that were not based on the IE engine, and therefore was never a reliable solution for most sites - even at the peak of IE's market share, some portion of website visitors would not see the specified fonts. Currently, approximately 35-40% of a site's visitors will not see them, depending on the market share of IE.

Firefox (since version 3.5), Opera (since v.10) and Safari (since 3.1) all support the @font-face CSS property, which allows the designer to specify a font face in TTF or OTF format, and an address where the font can be downloaded. Again, market share of these browsers is limited, and all of the larger issues of using embedded fonts apply.


As mentioned, another way to embed fonts is, of course, to make images of them. Here, too, the web has evolved. It is now possible, depending on the software installed on the server side, to generate these images statically (at the time the design is created, in which case the text is fixed at the point of creation) or dynamically (generated on the fly by a graphics library installed on the server). While dynamic creation of  images of text is beyond the scope of this article (see http://www.experts-exchange.com/A_1898.html for an excellent tutorial), images of text remains a viable approach.

Drawbacks include the fact that the text cannot be read by search engines or screen readers, creating SEO and accessibility issues. With modern CSS techniques, there are some ways around this, but it's still clumsy. And, with dynamic generation of images, this becomes more difficult still (and font licensing for fonts placed on web servers remains an issue). Download times are also greatly increased, and with the growing widespread use of mobile phones and netbooks on limited or throttled bandwidth connections as a means of browsing, download time remains an important issue.


A relatively new technique uses flash to substitute a flash file with the desired font for blocks of text, but it can be tricky, and has it's own drawbacks. The technique is called sIFR (scalable Inman Flash Replacement). Essentially, you replace short bits of plain text rendered in the default or CSS-specified font with text rendered in your selected font by a combination of javascript, CSS, and Flash.

Here's the official page of the original sIFR, with more information, how-to's, and links:
http://www.mikeindustries.com/sifr/

Since then, sIFR has evolved, and the latest is version 3:
http://wiki.novemberborn.net/sifr3

Some drawbacks of sIFR:






The final drawback of sIFR was that the designer had to have and be at least somewhat proficient in Flash software to create the required files. The importance of this drawback has decreased with both web-based (sIFR Generator) and downloadable (sIFR Font Maker by CoffeeCup Software) software tools to create the Flash files. You may have to take extra steps to ensure you have the right version of the sIFR javascript to work with a particular generated SWF.


Conclusion:
Work continues at the World Wide Web Consortium (w3c) on a dynamic font specification via a Fonts Working Group, so we remain hopeful that eventually a cross-browser solution will arise. However, as yet, there is no holy grail. Each of the possible approaches come with their own set of issues and drawbacks.  All of them complicate your design; some of them limit accessibility and search engine optimization (SEO) in various ways. None of these are necessarily show-stoppers, just trade-offs (like many others we make as we design web pages) that you should be aware of, until a better solution arises.

Until then, my Quest is to seek the Holy Grail, and my favorite color is Blue.