Category Archives: Fonts

Typekit Hopes to Become the YouTube of Fonts

A new startup is hoping to solve the web’s font problem.

Designers have been bemoaning the state of typography in the browser since the dawn of the web. The current technology for rendering type in the browser without using Flash or other non-standards-based methods essentially limits designers to only six fonts.Of course, we already have some ways around those limits, like sIFR and Cufn, two projects that use Flash and JavaScript, respectively, to embed fonts on web pages from the server side. However, there’s long been a better way to embed fonts waiting in the wings: using CSS.

The W3C @font-face declaration for CSS has been around for some time, but has languished due to two big problems. First, most browsers didn’t support it. But with the latest versions of Safari, Firefox, Opera and Google Chrome all now supporting @font-face, that problem is close to being solved.

It’s the second major problem that’s the sticking point: licensing restrictions forbid embedding fonts via CSS. Unfortunately, the font foundries which create, sell and license fonts have thus far been reluctant to embrace licensing terms that would allow designers to serve fonts legally. The foundries fear that users would be able to pirate the fonts much more easily if the files were published in the wild on the web.

It’s this problem that Typekit, an as-yet-unlaunched web service, is trying to solve. Typekit is the brainchild of Jeffrey Veen, a noted web designer (and former engineer and contributor to Webmonkey) who is hoping that Typekit can strike a deal with the font foundries and provide licenses that will allow designers can use them on the web.

Although Typekit’s official announcement is thin on details, it looks as though the company will host the font files, which designers can then license for a fee. From there, the fonts could simply be embedded using the @font-face declaration in a site’s stylesheets.

Sounds prefect right? Well, maybe. There are some possible problems with Typekit’s scenario.

First, there’s the issue of potential downtime. If Typekit’s servers choke (and even Amazon’s S3 service goes down from time to time, so don’t expect Typekit to be any different) all your fancy fonts vanish. Depending on how complex your design is, an outage could turn your site into a garbled disaster.

The other possible problem is that Typekit will require adding “a line of JavaScript to your markup.” Hopefully what that means is that you’ll need to embed a license checking script. But the announcement isn’t clear about this, and some commenters seem to think it means Typekit is planning to use a font replacement system along the lines of Cufn.

Update: According to Typekit’s Jeffrey Veen, the commenters have it wrong.

“Typekit isn’t using any sort of image replacement for rendering fonts on web pages,” Veen tells Webmonkey. “We’re using the CSS @font-face declaration to link to TrueType and OpenType files. We’re using JavaScript to simplify that process and account for various browser versions.”

Ah, yes, various browser versions. At the back of everyone’s mind is the problem of Internet Explorer — Even the brand new IE8 still does not support the @font-face rule. However, after watching the developments come out of Google’s I/O conference it seems pretty clear that the web is moving forward with or (more likely) without IE.In the meantime, Veen says Typekit is taking special considerations to deal with Internet Explorer.

But over time, using Internet Explorer will result in a second tier web experience, since the browser remains without HTML5 and CSS 3 support. Users will start asking why, and one of two things will happen: either users switch to a different browser or Microsoft adds the missing features. Either way, the web wins.

Assuming @font-face support becomes ubiquitous across all browsers at some point, font foundries and Typekit may well find themselves in the same position that the music and film industries are today — fonts will be embedded using @font-face directly, regardless of copyright laws.

Despite the potential problems and complexities, we welcome the impending arrival of Typekit. If it can work around these outstanding issues, it has a good chance of succeeding. If you’d like to be notified when the service is available, head over to the sign up page and add the blog feed to your RSS reader.

Web Typography Tutorial – Lesson 2

Ask any web designer about the use of typographic design on web pages and they’ll tell you the same truth: The web is a harsh, uninviting environment for the delicateness of fine typography. Along with the usual web culprit of platform inconsistency, the extreme low resolution of even the best current screens means type online can only allude to the geometry of the typefaces you’ve so carefully chosen and specified.

The Devil’s in the Display

The fundamental problem of online type has nothing at all to do with the Web. The problem — whether you’re building pages for a website, CD-ROM, Palm Pilot, cell phone, or museum kiosk — is the display. On a computer screen, at least at relatively small sizes, Helvetica is not Helvetica. The chunky pixels on a 72- or 96-pixel-per-inch screen can’t possibly match the subtle curves of type.


This means that for body copy, we can barely produce legible type, let alone make subtle stylistic distinctions. What we’re left with is the grossest conceivable control – straight versus slanted, static versus dynamic, old versus new, light versus heavy, serif versus sans-serif. While it will take radically-better displays to bring onscreen typography up to the standards of the ancient Romans, there are several techniques which do help somewhat.


  1. Pushing Pixels
  2. HTML and CSS
  3. When is a Point Not a Point?
  4. GIF Images
  5. Flash
  6. Trouble in Paradise
  7. SVG
  8. Acrobat
  9. Resources On the Web and In Print
  10. Suggested readings


Pushing Pixels


The problem of translating curves to pixels can be mitigated in larger (i.e., display) sizes by a technique called anti-aliasing. Anti-aliasing is the process of tricking the eye into seeing smooth curves instead of jagged pixels by using colored pixels around the edges of letterforms. Because the pixels are intermediate in tone and color between the type color and background color, they have the effect of smoothing out the curves.


The two problems with anti-aliased text are:

  1. it looks fuzzy, and
  2. it only works with relatively large sizes of type.

When used with body sizes, anti-aliasing often only produces a mushy mess. An interesting secondary consideration for the Web is that anti-aliased text may appear more corporate or polished and less “immediate” than straight HTML text.


At small sizes, there’s only so much that can be done to improve on-screen legibility and fidelity to the “real” typeface, and it’s done with a technique called “hinting.” Hinting is a method of tweaking the outlines of letterforms so that they match up as well as possible to the screen’s pixels in order to produce the closest possible – or at least less mangled – reproduction of those ideal outlines. Hinting information is included as part of a typeface, so it’s not something you’ll need to do yourself, but if you’re interested in the gory details, take a look at this Microsoft article on hinting in TrueType.

While the practice may be esoteric, the results of good hinting can be quite dramatic. Compare, for example, the following samples of the same text (more or less) set in the meticulously hinted Verdana as compared with Helvetica.


Now you know why the vast majority of commercial Web pages created in the last year use Verdana. (There’s a second, related, reason:Verdana, designed by Matthew Carter and hinted by Thomas Rickner, was originally designed as pixel-friendly bitmaps. Once those were just right, Carter made outlines from the bitmaps instead of the more-common practice of designing outlines and then trying to generate bitmaps. Another screen-friendly face is Georgia, designed and hinted by the same team.)


Another option, especially for really tiny sizes is to use bitmapped typefaces. Since they’re designed specifically as bitmaps, without curves at all, faces like Silkscreen and Mini7 don’t have the same problem traditional outline fonts have onscreen. On the other hand, because they’re designed to the pixel, they work only at the specific sizes for which they were designed. Still, an entire visual style has arisen from these tiny pixellated fonts.



Even if display resolution wasn’t an issue, type online faces a second major problem:the familiar bugaboo of platform inconsistency. This takes several forms, including different browser and plugin capabilities and – most challenging – different installed typefaces. We’ll take a closer look at these issues as we discuss the various technologies for specifying type on the Web:HTML/CSS, GIF images, Flash, SVG, and Acrobat.



The current XHTML spec provides rudimentary font control with the FONT tag, which allows page authors to specify typeface and rough size, like so:

1 <font face="Verdana" size="3">

However, this technique, while widely practiced now, is currently being phased out in favor of Cascading Stylesheets. CSS provides significantly more control, which we’ll explore in depth a little later. However, as giving and wonderful as they are, even HTML and CSS have several problems in common. Perhaps the biggest headache arises from the fact that people viewing our meticulously crafted pages may be seeing them in a totally different font than we intended because not everybody has the same typefaces installed on their machines.


But, you protest, we can just embed the fonts. And we certainly can, and probably should, but we will still have to assume that a significant portion of our audience won’t ever see them. Probably the two biggest reasons more people don’t embed fonts are that the tools have really confusing interfaces, and we still have to design around the possibility the fonts won’t be downloaded. This paragraph, for example, is set to be displayed in Gill Sans and I’ve embedded the font, but many of you will see it in the default font for this page instead (which probably looks a lot better in this case). For the full scoop on font embedding, check out Mulder’s excellent tutorial.

The Shotgun Approach

If we can’t fully rely on embedded fonts, we’re stuck with guessing what our viewers might have installed. Luckily, we have a few techniques to help us. First off, the HTML FONT tag and CSS font-family property allow us to specify a list of faces, such as “Verdana, Arial, Helvetica”. The browser will display the first typeface in the list which is available.

Next, we can make educated guesses based on default Windows and Macintosh fonts and the fonts installed by recent versions of Web browsers. Microsoft has a page listing some commonly installed fonts (and not only Microsoft ones). The default fonts are so limited, in fact, that we see the same strings over and over on Web pages:”Verdana, Arial, Helvetica”, “Georgia, Times New Roman, Times”, “Courier New, Courier”.

Commonly-installed typefaces on Macs and PCs

Windows MacOS
Serif Georgia

1 MS Serif
3 Book Antiqua
5 Times New Roman

1 New York
3 Palatino
5 Times
Sans-serif Verdana

1 MS Sans Serif
3 Arial
5 Trebuchet

1 Geneva
3 Helvetica
5 Chicago
Monospace Courier New Courier
*Georgia and Verdana are installed on Macs by MSIE, so they may or may not be present.

Generic Families

Finally, we can use generic family names – ‘serif’, ‘sans-serif’, ‘monospace’, ‘cursive’, and ‘fantasy’ – to tell the browser to use the closest available face. (I have to take issue here with the absurd notion that “fantasy” should be one of these five core generic families – that one must have been added during some after-hours partying over at the W3C.) Finally, keep in mind that, as put in the CSS 2 spec, “Generic font families are a fallback mechanism, a means of preserving some of the style sheet author’s intent in the worst case when none of the specified fonts can be selected.”

“Verdana, Arial, Whatever”

So, if you want a sans-serif face, you just plop in “Verdana, Arial, Helvetica, sans-serif” and you’re good to go. If people look at your site and don’t have Verdana installed, they get Arial or some other sans-serif face and we can all move on to reading your brilliant article about collecting toy robots. Right? Well, yes and no. The mechanism works fine, but shoot – if all sans-serif faces looked the same, there would be no point to my writing the whole first part of this article. A second issue – especially important for body type – is that, as we’ve learned, different typefaces at the same point (or pixel) size can appear to be quite different sizes. Indeed, the CSS 2 spec addresses this problem with the font-size-adjust property and also includes a detailed algorithm for more specific font-matching, so we’ll still have degradeability but with at least some more control over the actual shape of the letters rather than their membership in hopelessly broad families like “sans-serif” and “serif.”

As a side note, there is a particularly funky hack for detecting installed fonts. It involves using JavaScript to compare the relative sizes of a layer of text set in the default face with one set in the face you’re testing for. It’s fairly ugly, but works surprisingly well. Unfortunately, there’s not all that much you can do with that information once you have it.


When is a Point Not a Point?

Type is traditionally (i.e., in the print world) measured in a unit called a “point,” which is 1/72nd of an inch on paper. But screens are based on pixels, rather than points. On the original Macintosh, there were close to 72 pixels per inch on the screen, so points and pixels matched up quite nicely, thank you. But now, displays and resolutions vary widely and Macs and Windows machines make significantly different guesses about them. Without getting into the gory details, type specified in points (or any point-based measurement) will appear larger on a Windows machine than on a Mac.

One solution is to conditionalize your type sizes for different platforms if using CSS or HTML. Another is to use the CSS “px” (for pixels) unit, which will force everything to the pixel grid. The primary drawback is that text set in pixels will generally foil user-defined text sizes. This can cause usability problems, especially if you’ve chosen particularly small sizes. It also may cause printing trouble (if the printer tries to translate your pixel sizes into points – more on CSS and printing in a moment). But for now, the alternatives may be worse.

In HTML, all we can specify is family and a rough measure of size. With CSS, however, not only can we specify exact size increments, but we can control such crucial properties as line-height, word-spacing, and letter-spacing (for more on using these properties, see lesson 3 on word- and letter-spacing and line-height). Line-height alone goes a long, long way to improving the readibility of a Web page.

Another advantage of CSS is the ability to specify different stylesheets for different output devices. The most obvious example is to include a separate stylesheet for printing a page (specifying different typefaces, perhaps, or using points rather than pixels for sizing), like so:

01 <style type="text/css" media="print">
03 .someClassName { font-family:Bodoni, Georgia, serif; font-size:10pt }
05 </style>
09 <style type="text/css" media="screen">
13 .someClassName { font-family:Georgia, serif; font-size:12px }
15 </style>

or, linked, like so:

1 <link rel="stylesheet" type="text/css" media="screen" href="screen.css" />
3 <link rel="stylesheet" type="text/css" media="print" href="print.css" />

Finally, I wanted to point out what I see as a big problem with using CSS/HTML for specifying type:Designers still lack control over anti-aliasing, especially in display type. Depending on your visitor’s particular operating system and settings, type will either be anti-aliased or not. You, as a designer, have no control, which is a darn shame because, as you now know, anti-aliasing doesn’t make sense for all typefaces at all sizes.


GIF Images

You may think that the lack of control over the way type displays on screen is no big deal. You can just make all your type out of images – GIFs or JPEGs – right? Well, yes and no. Using images to specify type looks at least as good as anything else onscreen and can be seen by almost all browsers, but it also introduces a number of serious problems.

The first problem is that images take up more file size than plain text, which can lead to slower display of your page. Related to this is the issue that each image (and a single page can have many if each header or navigation element is treated as an image) will require a separate server connection, again slowing down the time it takes for your page to display.

Besides speed issues, text in images isn’t selectable or copyable. And it’s not viewable by text browsers such as Lynx or screen readers for blind Web surfers. The workaround is to religiously use the ALT attribute of the <img> tag, which you should absolutely do. (If you’re not sure what to write, there are plenty of detailed ALT text guidelines on the Web.) Finally, text in images is fixed in size, which means it cannot scale along with non-image text on your page.

In addition to its considerable, though not insurmountable, usability problems, image text can be a pain to manage. Changing text contained in an image requires an image-editing program and the ability to use it, often the organizational province of a graphic designer, while plain text can easily be changed by a copyeditor or other member of a Web production team. Similarly, a change in visual treatment requires changing all images on a site. This is especially significant on a large site where a single change may occur across many images. By contrast, CSS-styled text can be changed simply by editing the appropriate style rule. Finally, text in images is not so easy to generate dynamically (although it certainly can be done). The bottom line is that images are not generally appropriate for personalized portions of a site.

Where images do make sense for text is in navigation or title treatments, where carefully specified and anti-aliased display type can make a site feel much more polished and expressive than jagged default HTML type. Just make sure not to forget about ALT text and consider using plain text if you have a large number of items, such as the navigation on a large news site like CNN.



The reason images are so wasteful of bandwidth is that they’re based on pixels rather than a more efficient method of describing visual information, such as [[Reference:Vectors | vectors]. So it stands to reason that a vector-based way of rendering type might make more sense for the Web. The most obvious current choice is Macromedia’s Flash.

In terms of type, Flash offers several advantages. The first is file size, as you can see in the following example:

Flash:548 bytes


Gif:1,459 bytes

As you can see (assuming, that is, you have the Flash plug-in, which we’ll discuss later), the GIF is almost three times as large as the Flash version. Since Flash is all based on vectors, in fact, the larger the type, the bigger the file-size savings. Double the size of the type, and the Flash file will still be only 548 bytes. The second advantage (as you can see above) is selectability. You should be able to select the text in the Flash example and then copy and paste it. Finally, Flash text can be pulled from an external source – an XML file or a Web server for example – which means both that content management is less a problem than with image files and that text in Flash can be dynamically generated, which as I’ve mentioned is relatively difficult using an image.

For static text in Flash, there’s no need to embed the font as it will be saved as outlines. For dynamically updated text, Flash supports embedding of fonts, either an entire font or specific glyphs. As with CSS font embedding, the font data can be saved as a separate file and linked from multiple Flash movies. It’s also possible to tell Flash to handle type similarly to how HTML and CSS do, by using “device fonts,” although you’ll be limited to the generic groups (‘_serif’,’_sans’, and ‘_typewriter’). And don’t forget, with Flash, you can make your type dance and twirl and fade in and out. I’m not saying you should, just that you can.


Trouble in Paradise

But Flash has problems of its own. One of the big ones has to do with anti-aliasing. The trouble is that Flash has no ability to selectively turn anti-aliasing on and off. Either everything in the movie is anti-aliased or nothing is. It sure would be nice to be able to use, say, 10pt Georgia for big blocks of text with no anti-aliasing and still have nice anti-aliased 36pt titles. Are you listening, Macromedia?

Another significant problem is that Flash files included on your pages won’t get printed along with the rest of the page. Flash has an internal print mechanism, so you can add a print button to a standalone Flash site, but that won’t help with Flash embedded along with HTML in a Web page. If you print this article, for example, you’ll see only empty boxes where the Flash samples should be.

Then, of course, there’s the fact that Flash is a plug-in rather than a “native” Web language like HTML. This is a legitimate concern, but at this point, after years of browser manufacturers forcing proprietary capabilities on us while ignoring established specifications (like CSS), I’m not sure what’s so “native” about HTML and CSS. And Flash is quite widely distributed, with Macromedia claiming over 90 percent “penetration” worldwide. Still, not everyone who visits your site will have the plugin, let alone the latest version. So you’ll want to consider whether you need to have a separate version of your site for non-Flash users. Recent versions make this more feasible by allowing you to store content as XML, readable by Flash and relatively easily convertible to HTML for accessibility.

Finally, many people have pointed out glaring usability problems in Flash movies, often attributing the lack of usability to Flash itself. It’s important to understand that many of the common problems (such as long intro animations, obfuscated navigation, and frustrating, non-standard scrolling mechanisms) are due to poor design rather than some inherent aspect of the authoring tool. On the other hand, Flash does have some definite problems, such as its inability to respond to the browser’s back button or to allow the user to bookmark a specific “page” in a Flash movie. Many of these issues can be overcome with good interaction design – the back button is less of a worry, for example, if you don’t force your visitors into a navigational dead-end – but they may require extra attention. For more on Flash usability, take a look at Macromedia’s Flash accessibility pages or Flazoom’s usability section.

If you’re new to Flash and want to learn how to use the darn thing, visit the Flash Tutorial for Beginners. For more on pixels and vector graphics, take a look at Web Graphics for Beginners.



SVG, like Flash, is a format for describing vectors. In fact, you can think of SVG as a sort of W3C-sanctioned version of Flash, although there are some important differences, most notably that SVG data exists as plain text, rather than in a binary format as does Flash, and that that text is formatted as XML. In fact, once you get past all the contextual stuff like document type declarations and so on, SVG is a pretty straightforward way of describing shapes:

01 <rect
03 x="100" y="100"
05 width="400" height="50"
07 fill="#33cc33"
09 stroke="#000000" stroke-width="2"
11 />

Much of the promise of SVG lies, in fact, in its promise. As it exists today, it can only be viewed by people who have installed the Adobe plugin. OK, there are lots of SVG viewers out there, but I’m talking about regular people, not geeks who install development applications. But the idea of being able to handle vector graphics side-by-side with HTML and XML is quite powerful. For animations, it remains to be seen if SVG can compete with Flash, but for static type, SVG could be a godsend. SVG, like Flash, includes several methods for embedding typefaces.

I want to point out something here:Flash is a relatively mature authoring environment which happens to output movies in a particular binary format. As such, it has a great advantage over SVG, no matter the benefits of SVG’s strict XML format. Right now, this is probably the most important distinction – aside from plug-in distribution – between the two. This doesn’t mean that SVG won’t have its own authoring tools – it will. Indeed, Illlustrator 9 already supports SVG and LiveMotion eventually will as well. Or, just as likely, we’ll soon use Flash to generate SVG.

There’s growing support for SVG on the viewing side, including both Web browsers and mobile devices. It seems fairly safe to say that either SVG will be a usable part of our lives relatively soon or, if not, that Flash and SVG will converge enough to make the distinction moot.



And then there’s Acrobat, an entirely different animal. Instead of operating within a Web page, Acrobat files operate in their own self-contained universe. This means on one hand that you’d never use Acrobat to make page titles for a Web page. On the other hand, Acrobat promises precise control over the design of a page. The key word here is “page.” Think of Acrobat as an excellent way of distributing paper-like pages over the Internet.

Acrobat files will print exactly as authored, so they can be great for publishing reports or other documents that require graphic and typographic precision. On-screen, however, they’re more than a bit clunky to navigate, often seeming either a bit too large or a bit too small for comfortable reading. Accessibility can also be a problem, although Adobe has done quite a bit to address this with the latest release (Acrobat 5) and by providing tools like their Acrobat to HTML converter. Like Flash, Acrobat requires a browser plugin.

Finally, despite free and paid converters online, you’ll likely want to invest in the full version of Acrobat for satisfactory control over your output.


Resources On the Web and In Print

Whew! For a brief introduction to typography online, that’s a whole lot to digest. But now you hopefully know enough to choose and set type with confidence, and you can work around some of the problems of using type online. If you want to learn even more, I encourage you to explore the following resources I’ve included below.

Selected resources

Type foundries

  • ( is a Reseller of typefaces for many different foundries.)
  • Adobe
  • AGFA-Monotype
  • Bitstream
  • Emigre
  • FontBureau
  • FontShop
  • House Industries
  • ITC (International Typeface Corporation)
  • Linotype Library
  • P22
  • Storm
  • T-26
  • Free fonts:there are loads of sites offering free fonts for download. Many of them are quite nice, but many more are relatively shoddy, either in design or in quality. In general, you’re best off buying a small number of high-quality fonts from a reputable source. This may also encourage you to use fonts to support text rather than the other way around. As [/webmonkey/html/96/46/index2a.html Kristin wrote] way back in ’96, when it comes to type, “Simple is almost always best.”


  • Typographic Design:Form and Communication
  • The Elements of Typographic Style
  • Stop Stealing Sheep & Find Out How Type Works
  • A History of Graphic Design
  • The End of Print
  • Typography
  • FontShop FontBook
  • Precision Type Font Reference Guide

Magazines and other typography resource sites

  • Web Page Design for Designers
  • Microsoft Typography
  • U&lc:Upper & lowercase Magazine
  • FUSE
  • Createivepro – fonts
  • Robin Williams’ Type Talk
  • Fontsite
  • Type books
  • x-height
  • Lines & Splines
  • Textism

A hopelessly incomplete list of type designers worth knowing

  • Aldus Manutius
  • Francesco Griffo
  • Claude Garamond
  • William Caslon
  • John Baskerville
  • Giambattista Bodoni
  • Morris Fuller Benton
  • Frederic Goudy
  • Eric Gill
  • Jan Tschichold
  • Paul Renner
  • Hermann Zapf
  • Adrian Frutiger
  • Paul Rand
  • Herb Lubalin
  • Saul Bass
  • Erik Spiekermann
  • Susan Kare
  • Neville Brody
  • Matthew Carter

I encourage you to take some time and browse these resources. Pick up a book or two on type. Find a few designers whose work is appealing to you, and then check out their friends. But just remember, the best way to learn about type — or anything else in design for that matter — is by experimenting. So, after reading up and looking around for inspiration, pull out your sketch book or start up your favorite graphics program and do some sketches. And when you think you’re done, do some more. And before you know it, you’ll be a typography pro!


Boing Boing’s Redesign Uncovers the Dark Side of Web Fonts

Culture news site Boing Boing recently tried a daring experiment — redesign its immensely popular website using some largely untested tools of the open web.

Unfortunately for Boing Boing, its ambitious plan resulted in a small disaster.

The team decided to use CSS3′s @font-face rule in its recent site redesign, which would enable it to use a custom font to display its text. However, far from delivering the look BoingBoing was going for, @font-face fell flat on its face; when the changes went live Tuesday, not only were the fonts Boing Boing wanted to use not legally available for the web, the font it settled on — specifically BPreplay — ended up looking terrible for most users.

The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.

Web designers have long been pining for open source tools that would afford them more control over site designs, including the ability to create animations, complex layouts and — probably the biggest wish-list item — the ability to use original typefaces and proprietary fonts in their designs. Many of these things are currently being written into into HTML5 and CSS3, two next-generation open standards for building well-formed web pages. We’ve even praised CSS3′s font-face rule and talked about how you can legally use it today.

The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-aliasing turned on by default. The rule, which is still part of CSS3′s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, “like ass.”

Beschizza, who like many Boing Boing contributors used to work for, spoke to Webmonkey over e-mail shortly after the redesign launched and after the feedback started pouring in.

For those using Windows Vista or Mac OS X, Boing Boing’s redesigned headline fonts looked just fine. Indeed much of the experimentation so far with @font-face is happening on designers’ blogs and portfolios — sites where the audience is likely to be using a modern browser and a modern OS.

If your audience is limited to people who live on the web’s cutting edge, then @font-face works pretty well.

However, for sites like Boing Boing, which has much broader audience, Windows XP and older browsers are still a significant portion of daily traffic. And while browsers that don’t understand @font-face (such as Internet Explorer) were fed a typical web font, in this case Verdana, the combination of modern browser and older OS proved disastrous.

But even practical issues like improper font rendering weren’t the only problem Boing Boing faced trying to use @font-face.

The font BoingBoing ended up using, BPreplay by the design group backpacker, wasn’t its first choice, but rather, because of licensing issues, its only legal choice.

“Our first pick for that headline font was VAG Rounded, which Mark (Frauenfelder, co-founder of Boing Boing) had used in his first mock-ups for the design,” says Beschizza, but the foundry didn’t offer a license for web display.

In fact the design team went through a whole list of font choices before they found one that was legal and fit their design.

Given the outcome, it isn’t hard to see why some foundries don’t want to license their fonts. Forget about @font-face making the actual font files available for download — if the fonts look terrible, no one will want them anyway. In fact, the foundry that makes one font Boing Boing tried to license cited appearance as the main reason they were declining to license the font.

So does that mean there isn’t going to be a way to use @font-face until Windows XP is a dim memory? Well you could always use JavaScript to detect the operating system and selectively applying @font-face to an OS that can render it. That (among other things, like licensing complexities) is one of the potential problems startups like the TypeKit project are hoping to solve.

Of course there’s always another option — just ignore Windows XP users. For smaller sites that may be a viable option, but for sites the size of Boing Boing the only real alternative is to do what Boing Boing did — revert to good old Helvetica and call it day.

Eventually web fonts will work, but for now they remain well out on the cutting edge. So, if you’re working on a large site, tread with care.

Review: Typekit Delivers Custom Web Fonts to the Masses

A new service called Typekit is now offering a legal, cloud-based method of using more elaborate typefaces on the web. The service has come out of beta and is serving up its fonts to web designers.

Despite some inconsistencies between browsers (not Typekit’s fault) and a few other quirks, we found Typekit to be a viable option for web designers looking to incorporate custom fonts into their designs.

Typekit is like a YouTube for fonts. Browse through Typekit’s library of available fonts, pick one you like and cut and paste some code into your site. As we noted when we first looked at Typekit earlier this year, the service is one of the easiest ways for web designers to use creative fonts without sacrificing web standards or violating font licenses.

Of course, that ease and convenience doesn’t come without a price. There is a free trial option for Typekit, which allows you to test out the service. But if you’re serious about custom fonts, you’ll want to go with one of the paid options which range from $25 to $250 per year. The more you spend, the more font choices, domains and bandwidth you’ll get.

Typekit arrives at a time when type on the web is at a crossroads. For years, designers have been limited to using only a set of five or six common fonts on web pages. But thanks to new font-rendering tools within the emerging HTML5 and CSS3 standards, web designers now have the ability to use newer, more visually interesting typefaces — and make that type appear more consistently across browsers, operating systems and screen resolutions. Even with these new abilities, intervening forces like DRM, licensing restrictions and varying levels of support from the browser makers have stalled progress, forcing the modern designer to resort to a variety of workarounds and hacks if they want to use these new fonts.

Along with Typekit’s arrival, we’ve seen other promising developments recently, like the move by some browser makers towards adopting a new font format called WOFF which would allow better control over layouts and designs.

To see how Typekit performed in the wild, we opted to try out the free option and see if Typekit was good enough to warrant the expense. The short answer is yes, but with some drawbacks.

Before you dive in to Typekit, it’s important to remember the one very large caveat — Typekit only works in browsers that support the CSS @font-face rule. That means Firefox 3.5 and higher, Safari 3.4 and higher, and Internet Explorer 6 and higher.

While that’s not ideal, the good news is that browsers that don’t understand Typekit’s fonts can simply fall back on a default you’ve defined.

There is another slight problem, though. In some cases, fonts rendered in browsers on Windows XP can look jagged and difficult to read. The problems is that Windows XP often doesn’t have anti-aliasing turned on by default. Of course it’s worth noting that even if you don’t use @font-face, standard fonts will also be jagged on such systems. The difference is that most of the standard fonts are still readable, while in some cases custom fonts become a total disaster.

To get started with Typekit, just create an account and tell Typekit the domain where you’ll be serving the fonts. We were happy to see that Typekit will support the localhost domain for testing purposes, something many online services and APIs overlook.

After your account has been created and your domain set up, Typekit will then give a snippet of HTML to include on your site. The code simply loads Typekit’s JavaScript library; all you need to do is paste the HTML in the <head> of your site.

Now it’s time to pick some fonts. Typekit’s range of fonts depends on the amount of money you want to spend. For a trial account, you’ll have just under 70 fonts to choose from. The “personal” library ($25/year) has roughly 230 fonts and the full library ($50/year) nearly 300.

The Typekit font-browsing interface is very well designed and offers some nice tools for choosing a good font — like a live preview of the font and numerous size previews for judging readability.

Typekit’s live preview tool with custom text. Click the image for a larger view.

Once you’ve selected a font, you’ll need to configure it for your site. The Typekit editor lets you control which CSS selectors your custom fonts will be applied to, which weights and styles to use, and what font to fall back on for browsers that don’t understand @font-face.

If you’d rather apply a font to all elements on your site, you can define your own custom font-family rules in your CSS file, for example h1 {font-family: "tenby-seven-1"} would apply the Tenby Seven font to all headlines on the site.

Typekit’s editor tool for customizing fonts. Click the image for a larger view.

The next step is to publish your font, which then makes it available on your domain.

The results looked great in our testing, especially in Safari 4, which seems to render type a bit thinner than Firefox on the Mac. On the Windows side, the results were roughly the same between browsers that supported Typekit.

One thing that seems unavoidable with @font-face, whether it’s through Typekit or otherwise, is a brief flash of unstyled text. It’s annoying, but for now there doesn’t seem to be anything you can do about.

There are some other drawbacks — the need for JavaScript and the additional data that increases page load times — but so long as you’ve already accepted @font-face‘s shortcomings, Typekit makes the process of using it simple and easy. Other possibilities for broadening your type selection includeTypotheque and a new service Kernest.

Mozilla Throws Its Weight Behind Improving Web Type, Adopts WOFF for Firefox

Firefox users will soon gain the ability to see an even greater diversity of fonts on web pages.

Mozilla announced Tuesday that version 3.6 of Firefox, due by the end of the year, will support the new Web Open Font Format, orWOFF. Web authors will be able to include WOFF fonts in their page designs by linking to the font files in their code the same way they link to images and other downloadable files.

WOFF becomes the third downloadable font format supported by Firefox — version 3.5 included support for TrueType and OpenType font downloads.

But WOFF has two key advantages over TrueType and OpenType: WOFF fonts are compressed, so they download faster, and they include support for tags and other unencrypted metadata.

This is a significant step forward not only for the emerging open format, but also for type on the web in general, which is still stuck in a state of mild turmoil.

For years, designers have been limited to using only a set of five or six common fonts on the web. But thanks to new font rendering tools within the emerging HTML5 and CSS3 standards, web designers now have the ability to use newer, more visually interesting typefaces — and make that type appear more consistently across browsers, operating systems and screen resolutions.

Even with these new abilities, intervening forces like DRM, licensing restrictions and varying levels of support from the browser makers have stalled progress, forcing the modern designer to resort to a variety of workarounds and hacks if they want to use these new fonts. Some possible solutions have shown up, including the OpenType standard and a “middleman” licensing model proposed by the startup Typekit, but haven’t yet gained traction. Earlier this month, popular website Boing Boing launched a redesign using CSS3′s @font-face rule, but ran into problems when things didn’t render correctly on older machines.

WOFF doesn’t promise to totally solve the problem of browser compatibility — it still uses the same paradigm within CSS3′s @font-face rule where users are served a preferred font choice first, but are then offered backup choices if their browser doesn’t support the first one. And there are still special considerations for IE 8 users, as Microsoft’s browser supports @font-face, but only if you use the .eot font format.

What it does do is improve workflows for those using downloadable fonts in their designs.

Mozilla contributor John Dagget outlines the compression and tagging advantages on the Mozilla Hacks blog:

First, compression is part of the WOFF format so web authors can optimize the size of fonts used on their pages. The compression format is lossless, the uncompressed font data will match that of the original OpenType or TrueType font, so the way the font renders will be the same as the original. Similar compression can be achieved using general HTTP compression but because compression is part of the WOFF format, it’s simpler for authors to use, especially in situations where access to server configuration is not possible.

Second, the format includes optional metadata so that a font vendor can tag their fonts with information related to font usage. This metadata doesn’t affect how fonts are loaded but tools can use this information to identify the source of a given font, so that those interested in the design of a given page can track down the fonts used on that page.

Dagget also notes that WOFF fonts aren’t “secure,” so the format shouldn’t be used by foundries wanting to regulate the use of their work. However, over 30 major type foundries — including House Industries, Hoefler & Frere-Jones and ITC — are already endorsing the format, and Mozilla’s support should help foster its popularity.

You can read more about how WOFF is used, plus see examples on the Mozilla Hacks blog. You can also check out WOFF support yourself by downloading the latest nightly builds of Firefox and giving it a whirl.