l'atelier

a short history of rendering fonts on the web

In 1995, when I first started website design and in the days before CSS, the options for typeography on the web were pretty limited. The body type was dictated by the default font of the browser, specified by the web viewer. We could design a site with a readable sans-serif typeface only to discover that the viewer’s browser default font was set to 18px serif, which destroyed text flow around images, text set within buttons, the flow of the page and the look of the page. Display faces had to be rendered as .jpg or .gif images.

When CSS became available most of us used it primarily to style text. It was a great leap forward. However, the availability of fonts is determined by those that are present in the viewer’s OS. This remains the method that many people rely on, until @font-face came on the scene, so I’ll go into a little more detail in a later post. Rendering display faces evolved from images to Flash to Javascript.

sIFR (or Scalable Inman Flash Replacement)

sIFR became an alternative to image rendering with the chief advantage being that the font was not required to be present in the viewer’s OS. However, to view properly, the Flash player and Javascript must be enabled, otherwise the text is displayed in whatever is specified in CSS. Additionally, if the page contains several instances of text generated with sIFR, there can be a noticeable delay in the rendering of the text in the specified font. Security issues have caused some people to disable Javascript, but more conerning is the growing number of viewers affected by the Apple/Adobe war which makes Flash unavailable on the iPhone and iPad. In addition, sIFR can be tricky to install and use. Two leaps forward, one back.

Cufon

Cufon entered to solve part of the problem. The fonts still need not be present on the viewer’s OS, font rendering engine is web-based and relatively easy to use, the text is editable and Flash is not required, however Javascript must be enabled and the browser must support HTML5 (which leaves IE 6, 7 and 8 out). Additionally, some typefaces are not licensed properly so that uploading your typeface for rendering may not (strictly) be legal. However, if Cufon fails, CSS comes to the rescue and assuming you have styled the type class or tag with an acceptable alternative, all is not lost. We’ll call this a step forward, but not a leap.

@font-face generator

At this writing, @font-face, a CSS3 rule, is the next leap forward. To implement, font files must be compressed and served in format that are somewhat browser-specific. It does not rely on Javascript, the text remains editable and it is the most cross-platform compatible solution so far. The @font-face generator produces CSS that points to versions of the font to be served in compressed formats, according to browser type.

You may upload either TTF or OTF fonts that you own (with the proper licensing, of course) to the generator, or there are several sources for (non-free) versions of many common typefaces with pristine licenses, or there is at least one source for (free) typefaces. Warning: the free versions tend to be a little funky–some with haphazard letter spacing (print-quality kerning is not available for the web) or sloppy x-height consistency.

There are several options that help to overcome browser inconsistencies with the @font-face rule. That isn’t to say that there aren’t problems but most have work-arounds or, as ever, there is the CSS-fallback. A detailed description of @font-face, the options and work-arounds can be found on John Dagget’s blog.

There are still other solutions for web font rendering, such as Typekit (not free), but @font-face remains my preference. Whichever engine/method you use to render your fonts on the web, the old standards of good design still apply. No “ransom note” styling or using display typefaces for body text, please.

I have been keeping track of the visits to my clients’ websites that use Internet Explorer 6 (IE6), with the idea that some day the share of IE6 to total browsers will fall to less than 5%. At that point, I can justify not developing websites that support IE6. It’s frustrating to have to develop two versions of every website (for clients that expect to pay for only one): one for browsers that take advantage of current standards and one specifically for IE6, which is non-standard. Even 2nd generation browsers (Firefox 3, Safari 3) don’t entirely gag on HTML5 and CSS3. IE6, on the other hand, is so far behind in interpretation of W3C standards that it is necessary to develop a mirror site to accommodate the IE6-specific code.

I assumed that IE6 would finally drop out of the mix sometime in 2009 but it is holding pretty steady between 5 and 10% for a couple of years. What gives? Its use is not specific to developing countries. It seems like people would upgrade just to move away from a browser that not only is non-standard but a notorious opening for all sorts of malware.

So why don’t we just develop sites for IE7 and later (not that IE7 is exactly “standard”, either)? It seems that corporate use of IE6 as a platform for browser-specific applications is keeping the overall market share of IE6 at about 16%. This means that corporations and large organizations who have invested heavily in development of IE6-specific applications will be slow to adopt more current browsers, requiring them to rewrite these applications. It seems that IE6 will not go away anytime soon. This is a sobering piece of news.

The challenge: I had designed a printed page layout with a different visual element on each page to help to break up rather long narrative. The client wanted this to be a template for her website, including the text-wrapped image. Below is a (different) page mock-up using a similar visual element in the lower left corner:

To make the page look similar to the printed version, the text to had to wrap around the image, not just squarely around an image with float:left styling. However, this is not as easy as it seems. I was familiar with the “sandbox’ technique, in which a series of sandbox DIVs is defined that block out the image so that the text can flow around them. This is cumbersome and a little time-consuming. However I stumbled upon a relatively simple technique that takes advantage of the <canvas> element.

By way of explanation, the <canvas> element “creates a fixed size drawing surface that exposes one or more ‘rendering contexts’, which are used to create and manipulate the content shown.” The term “rendering context” merely refers to either a 2D or (sometime in the future) a 3D image. To “draw” something, the <canvas> element is called by a script. In this case, Jacob Seidelin has developed a script, known as prettyfloat.js (download here).

Using this small script you simply give your image a CSS class of either “sandbag-left” or “sandbag-right”, depending on how your image should float. If the browser does not support <canvas> and image data access, a fallback mechanism simply sets the CSS float property to “left” or “right”, degrading to the old rectangular text wrap.

First, save the script with your project files (in this example to the same directory as the HTML file).

The image needs to be either .png or .gif to work properly, meaning it must have transparent pixels in which the text block will flow up next to the opaque pixels. To achieve this, the open the image in Photoshop, then:

1. Open the Layers panel
2. Double click on the Background layer to unlock it and make it available to transparency. This will now be labeled Layer 0.
3. Create a new layer (Layer > New > Layer…) This will be a temporary layer on which you will draw a guide.
4. Using the Polygonal Lassso tool, draw the guide leaving enough margin for the text:



5. Using the Magic Wand tool, select the area to be made transparent
6. IMPORTANT: Click on Layer 0 to make it the active layer
7. Using the arrow keys on the keyboard, nudge the selected area 1 px to the right and 1 px up so there is no chance of a border of pixels along the straight edges
8. Press the [delete] (or [Backspace]) key to erase the pixels:
9. Save for Web & Devices using the PNG-24 preset

Now for the code:

In the <head> section of the HTML file, call the prettyfloat.js script:

<script src=”prettyfloat.js” type=”text/javascript”></script>

(Change the URL if you store your scripts in a separate directory)

The <body> section with just the wrapped text segment of the page is as follows:

<body>
<div class=”container”>
<div style=”position:relative; width:550px; height:450px;”> <img class=”sandbag-left” src=”flowers.png”>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget euismod ullamcorper, lectus nunc ullamcorper orci, fermentum bibendum enim nibh eget ipsum. Donec porttitor ligula eu dolor. Maecenas vitae nulla consequat libero cursus venenatis. Nam magna enim, accumsan eu, blandit sed, blandit a, eros.</p>
<p>Quisque facilisis erat a dui. Nam malesuada ornare dolor. Cras gravida, diam sit amet rhoncus ornare, erat elit consectetuer erat, id egestas pede nibh eget odio. Proin tincidunt, velit vel porta elementum, magna diam molestie sapien, non aliquet massa pede eu diam. Aliquam iaculis. Fusce et ipsum et nulla tristique facilisis. Donec eget sem sit amet ligula viverra gravida.</p>
</div>
</div>
</body>

A test of how this renders in different browsers (using Adobe BrowserLab–more about that later) reveals that Firefox 2.0 on Mac OS X looks as intentded:

Chrome on Windows XP renders properly:

However, as expected, IE7 on Windows XP does not, though the results are acceptable (sort of):

Most newer browsers now support the <canvas> element so this is really is a relatively painless way to achieve a layout that has the look of a printed page.