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.
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.
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.
A final complication in embedding fonts is that embedded fonts can be hacked to include malicious code, which can exploit security holes in browsers and related plug-ins. In fact, in 2010 one such exploit took advantage of the way the iPhone PDF viewer loaded embedded fonts, with a demonstrated ability to access and modify the iPhone operating system from a simple drive-by download of a malicious PDF.
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.
Now, the good news: all major browsers, including Firefox (since version 3.5), Opera (since v.10) and Safari (since 3.1), and MicroSoft Internet Explorer (with limitations) all support the @font-face CSS property, which allows the designer to specify a font face along with an address where the font can be downloaded. All of the mentioned browsers EXCEPT MicroSoft Internet Explorer (MSIE) support TTF or OTF font formats. However, market share of these browsers is limited, and MSIE only supports Embedded OpenType (EOT) formats (requiring more elaborate CSS for cross-browser support). Also, all of the larger issues of using embedded fonts still apply; in particular, awareness of the hazards of malicious font files should have a prominent place in designer/coder choices on using embedding fonts.
2. Images of Text
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.
3. Scalable Inman Flash Replacement
Here's the official page of the original sIFR, with more information, how-to's, and links:
Version 2 of sIFR is the most fleshed-out version, resources are here:
Since then, sIFR evolved, and the latest is version 3, which has not left Beta development:
Some drawbacks of sIFR:
In some cases, Flash areas can be "sticky" and not allow scrolling via mouse wheel (user annoyance factor).
Loading times in the font-replaced areas may be increased. The more you use it in a page, the more of an issue this can become.
The original sIFR doesn't work properly on clickable link text. This has been resolved in later versions, but be aware that different implementations of the Flash file containing the font may render links differently (in other words, you may not have control over link color, underlining, etc).
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
Given these drawbacks, and the continuing evolution of the @font-face CSS selector, sIFR will likely remain limited in real-world use.
The leading site for web-based Cufón generation is here: http://cufon.shoqolate.com/generate/
(but I'll note that IN THAT SITE, they use PNG images of text to display unique fonts. Oh, the irony).
This issue has evolved since I first drafted this article 2 years ago. The use of @font-face in particular is changing the patterns of use of other techniques that I discuss. The work at the World Wide Web Consortium (w3c) on a dynamic font specification via a Fonts Working Group
, has declined with the widespread implementation of @font-face in modern browsers. 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.