Dreaming Of Utopia
For a designer working in the Web medium, perhaps the most frustrating thing is the difference between the design he’s created on his whiz-bang 32-million colour SGI workstation, and the way it looks in Netscape 3.0 running on a 256-colour PC. Sometimes the colours don’t look right; sometimes the text is too large or too small; and sometimes those fancy dHTML effects don’t just refuse to function, they can actually break the browser.
One of the most common problems, though, has to do with the fact that when a user visits a Web page which has been designed using non-standard fonts, the browser will use default fonts to display the content on the page. Now, if the page was designed using 26-point Argus120 Bold Italic and the browser’s default font is 10-point Times New Roman, you can understand why the designer would be pulling his hair out in frustration…and why the user would be so turned off, he wouldn’t come back for a second visit.
In the past, a number of attempts - some of them quite ingenious - have been made to find a solution to this problem. One of the most common is to use an image instead of regular text for the content which is to be displayed in non-standard fonts. Since all browsers can display GIFs and JPEGs, many designers simply create an image containing text written in the special font, and stick it into the page at the appropriate points.
The downside of this approach is that it’s not very elegant - imagine a page which contains “regular” text and “image” text combined together, and then imagine how ugly that page would look to users on a slow connection. Even worse - what if the user’s browser is entirely text-based, or has images turned off? The page would be completely unreadable…
Another approach is to clearly state - as some foreign-language sites do - that the Web site requires special fonts to be correctly viewed, together with a link to the font files and installation instructions. The problem: most Web surfers don’t have the patience to download and install font files, and are more likely to click out of the site instead.
Finally, of course, you can just restrain your designers to designing with the fonts available on most machines. This is not a perfect solution - try telling a designer he can’t use orange PineTreeTop Bold and you’ll see what I mean - but it does offer the most practical solution to the problem to date. It also doesn’t address the issue of non-Windows browsers - for example, Windows PCs may have Verdana installed by default, but Linux boxes don’t.
Ideally, what is needed is a method to include the font file with the Web page, such that the font is rendered correctly in the client browser, regardless of platform or browser type, or of whether the font file is already present on the target client.
Enter embedded fonts.
The How Of Embedded Fonts
As you’ve probably come to expect from past history, both Netscape and Microsoft have adopted slightly different strategies to tackle the embedded font problem. The Redmond approach uses a technology called OpenType, while Netscape’s version is called TrueDoc, developed in partnership with Bitstream.
Despite the difference in nomenclature, the approach of both companies is conceptually similar: Web developers use an authoring tool to create a single font data file, and then link their HTML pages to this font file. When a user browses to a page containing embedded fonts, the browser automatically downloads the font data file, decompresses it to a temporary directory and renders the characters on the page in that font.
Both companies also provide authoring tools to assist in the process of building the font file. Microsoft’s tool is called WEFT, the Web Embedding Font Tool, and is currently in version 3.0; you can download it from http://www.microsoft.com/typography/web/embedding/weft3/default.htm If you prefer to stay loyal to Netscape, you can download a free 10-day trial version of Bitstream’s WebFont Wizard from the Bitstream Web site at http://www.bitstream.com
The browsers are also shaky on support for the competing technologies: Netscape Communicator 4.x supports Bitstream TrueDoc technology out of the box, while Internet Explorer users will need to download an ActiveX control from Bitstream’s Web site to correctly view TrueDoc font files. Conversely, Internet Explorer 4.x and above has built-in support for OpenType font files.
Both the Microsoft and Netscape versions of the technology come with one very important and useful feature: the ability to restrict font usage to a specific Web site or directory. This security feature is very handy for font authors and designers who want to protect their digital scrawls from the rest of the freeloading Internet.
Be True, My Doc!
We’ll begin with TrueDoc, the native format supported by Netscape Communicator. Once you’ve installed the Webfont Wizard authoring tool and started it up, it will ask you to select the font you’d like to embed into your pages. At this point, you can also select the script and style of the font.
Once that’s done, you also have the option of selecting which characters to include in the embedded font; typically, it’s a good idea to include all alphanumeric characters and punctuation, unless you have a specific reason not to. You will also need to specify the “allowed document roots” that can use this font - for example, if you’re planning to use the font on http://www.melonfire.com, you must specify this URL at this time. As described above, this is a built-in security feature designed to prevent unauthorized use of your fonts on other Web pages.
All done? Hit the “Finish” button and you’ll be presented with a Portable Font Resource file, identified by the .pfr prefix. This file contains all the information needed to render that font on a client PC, if it’s not already available.
Now that the font file is ready, you need to place it on your Web server, and include some code in your Web page to link to it. Typically, this code is placed in the <HEAD> of the page and looks like this:
<head>
<!-- Start link to PFR -->
<link rel=fontdef src="mfre.pfr">
<!-- End link to PFR -->
<!-- Start Bitstream WebFont Player support -->
<script src="http://www.bitstream.com/wfplayer/tdserver.js" type="text/javascript">
</script>
<link>
<!-- End Bitstream WebFont Player support -->
</head>
The Javascript code is necessary so that clients running Internet Explorer are automatically prompted to download the appropriate ActiveX control.
Now, within your page, you can use the <FONT> tag as you would normally - remember to use the correct name of the font, with spaces and capitalization in the right place!
<html>
<head>
<!-- Start link to PFR -->
<link rel=fontdef src="mfre.pfr">
<!-- End link to PFR -->
<!-- Start Bitstream WebFont Player support -->
<script src="http://www.bitstream.com/wfplayer/tdserver.js" type="text/javascript">
</script>
<link>
<!-- End Bitstream WebFont Player support -->
</head>
<body>
<font face="Staccato222 BT" size="+1">Am I looking good today or what?</font>
</body>
</html>
Now, when you browse to this page, you should be able to see the Staccato222 BT font in all its glory…even if you don’t own a copy yourself!
You can include multiple <LINK> tags in a single page in case you have more than one font to download. Fonts download in much the same way as images, which means that you might first see body text in the default font, which will then be re-rendered once the .pfr file has downloaded to your PC. Once the file has been downloaded, it remains in your browser’s cache until deleted.
Weft And Warp
If you prefer doing things the Microsoft way, you can use WEFT to build embedded font files which are natively supported on Internet Explorer 4.x and above.
The first time you install WEFT, it will scan your system and build a list of all available fonts; these fonts are then displayed to you in a neat table with icons indicating whether or not they can be embedded into your Web page (many font authors do not permit their fonts to be embedded, preferring instead to charge users for the privilege). Once the database has been built, WEFT will ask you for a list of HTML pages to scan, and will build a list of all the fonts used in those pages.
At this point, you can select a subset of glyphs to be encoded into the embedded font file (identified with the .eot extension), and have WEFT generate the font files for you. Your decision on which glyphs to encode (because more glyphs means a larger file) should be based on the extent to which you plan to use the font; if you’re using it for only a single line of text, it makes more sense to encode only a few specific characters.
WEFT’s documentation states that the program can also edit your HTML files to include the HTML code necessary to get the font files to work; however, my experience was that the program ended up corrupting the HTML file instead. It’s advisable to copy the code from WEFT’s template, and paste it into your Web documents yourself.
Here’s what a typical WEFT-enabled page looks like:
<html>
<head>
<style type="text/css">
<!-- /* $WEFT -- Created by: me ([email protected]) on 19-10-00 -- */
@font-face {
font-family: Staccato222 BT;
font-style: normal;
font-weight: normal;
src: url(http://www.melonfire.com/staccat0.eot);
}
-->
</style>
</head>
<body>
<font face="Staccato222 BT" size="+1">Am I looking good today or what?</font>
</body>
</html>
The CSS rule above will use the font located at the URL “http://www.melonfire.com/staccat0.eot” to render the characters on the page. Caveat: don’t expect this to work in Netscape’s browser.
Of the two approaches above, the TrueDoc format is preferable at the current time, since it allows users of either browser to view your embedded fonts correctly - a problem the OpenType format is yet to address. The WEFT tool is still under development, though, so keep checking the Microsoft Web site at http://www.microsoft.com/typography/ for updates on this issue.
Till next time…stay healthy!
This article was first published on 19 Oct 2000.