Now that browsers support real fonts in web pages and we can license complete typefaces for such use, let’s move past the hype of web type and think pragmatically about how to use real fonts in our web projects. Several experiments with the CSS
@font-face property, including some preliminary work with the much-anticipated Typekit, have led me to a single, urgent conclusion: I need to know how my type renders on screens, in web browsers. To that end, I created Web Font Specimen, a handy (free) resource web designers and typographers can use to see how typefaces will look on the web.
Markup-and-style samples for testing purposes are nothing new. You probably already have a go-to resource bookmarked, be it the W3C’s HTML element sampler or something homegrown. Web Font Specimen is very much like the sample files we find or make for ourselves, with two important distinctions: its sole purpose is to exercise a typeface, and it is ours to share.
Web Font Specimen is available under a Creative Commons Attribution 3.0 license. I welcome and look forward to your adjustments, iterations, and improvements. We’ll return to this issue in the context of buying and selling type.
Let’s quickly go over what Web Font Specimen looks like and how to use it. Afterward, we’ll discuss ways of paying closer attention to web type rendering—as well as how this approach will influence type sellers, type designers, and web designers.
Web Font Specimen#section1
Head over to Web Font Specimen, download the .zip file, and preview the HTML in a browser. You should see something like this example. Rendering will vary depending on your setup, but the example specimen should come through just fine (it’s plain old Georgia—most of you should have it installed, and it was designed to look good on screen).
Scroll down and you’ll see Georgia exercised in headings, lists, and with varying emphasis. There’s a body size comparison, different leadings (line-heights), a showcase of glyphs, different measures (widths), different sizes with uppercase and sentence case, grayscale text, light-on-dark text, and, an assortment of color combinations. Reasons for including each of these in the specimen are listed alongside a labeled screenshot at Web Font Specimen.
Fig. 1. Glyphs at 42px.
Fig. 2. Headings, lists, emphasis, and leading.
Fig. 3. Grayscale and color, light on dark.
Kick the tires#section2
Next, you will replace Georgia with the typeface you want to test. See the README file in the download for instructions on how to do this. For additional information, see two of my posts at Nice Web Type—“Where to get web fonts” and “How to use CSS @font-face.”
You may notice that Web Font Specimen is built atop Nathan Smith’s 960.gs, which is a great resource for quick layouts. Just as I have done with Nice Web Type likes reviews, the text.css file that comes with 960.gs has been replaced by one that is more streamlined for our needs.
All that’s left to do is test the result and decide for yourself whether the way your typeface renders across operating systems and browsers is, indeed, acceptable.
What this means for type sellers#section3
Part of the reality of type sellers’ changing business is that they suddenly have a huge new market for their goods and services. Sure, we web designers have always used type in our sites: Replacement techniques, images with
alt text, and fonts summoned with CSS have yielded some incredible typographic experiences (these and more are detailed at Typesites). However, we’ve rarely dealt with type the way print folks regularly do, because our experiences in web typesetting have always had more to do with the means than the end.
No more kiddie table#section4
For years, web designers have yearned to embrace typography in its fullest aesthetic and traditional capacities while bringing to bear all that we know about sound markup and universal accessibility. But the nature of our technical means for getting fonts into websites has acted as a barrier to setting realistic expectations for the appearance of web type on screens.
We’ve been so busy getting type into our sites, we haven’t had a chance to figure out why it looks the way it does when it gets there. As a result, web type rendering has largely remained a mystery. Rather than try to sort things out, we’ve simply treated web typography as a lesser art (with some wonderful exceptions), and our grumbles of dissatisfaction have reverberated.
Show us real type#section5
As web designers mentally overcome the print-is-better-than-web inferiority complex, type sellers know that a throng of new customers will expect to be treated fairly when browsing, sampling, and using type. Web Font Specimen is great when the typefaces we want to sample are in our possession. But when typefaces are locked within font delivery services, or behind a type seller’s shopping cart, how will we judge whether they are suitable for use in our web projects?
Type sellers need to provide some way to show the type they license for use with the CSS
@font-face property in its actual intended context. They are certainly welcome (cordially and legally invited, even) to use Web Font Specimen as part of a try-before-you-buy experience. I hope they will, and not only because of our need to see how typefaces will look on the web, but because their type adjustments, iterations, and improvements will make Web Font Specimen better. Web designers will be watching to see how type pros think type should be exercised, and we will adjust our toolbox specimen to take advantage of their advice—if they haven’t already done so for us by re-releasing a better iteration of Web Font Specimen.
What this means for type designers#section6
If type sellers are unable to or reluctant to find ways to show their type in context on the web, type designers will not be able to showcase the nuances they have worked so hard to achieve in their fonts. To meet web designers’ type rendering expectations will be a significant challenge. The lasagna of complexity between the beautiful letters type designers draw and the type we all see on websites is largely undocumented and full of variables.
From glyphs to web type#section7
Working through several Typophile threads with folks knowledgeable on the subject, I have tried to envision the gauntlet type must endure on its journey from type designers’ mathematical points and curves to Web Font Specimen’s grid-fitted shapes made of light. Here is my working list of steps, which has been improved with several suggestions and blessed by David Berlow as “pretty good overall.”
- A glyph starts as a bezier-based shape.
- This shape is made in or brought into a font-creation program such as FontLab.
- Settings such as UPM (units per em), key dimensions (for vertical measurements such as x-height, cap height, ascenders and descenders), and metrics (for horizontal measurements such as sidebearings and kerning) determine how the letterform will act as a glyph in a font—e.g., how much room it will occupy at a given size, how close other letters may live.
- Hinting or instructions are added (automatically and/or manually) which can provide directions to conserve the font’s design character in environments where less-than ideal output is to be employed.
- The glyph is exported as part of a font, in either OTF or TTF format (in this context, I am ignoring all other formats—let me know if I shouldn’t). TrueType hints are ditched if the font is OTF.
- The glyph is confronted by operating-system-level and browser-level rendering algorithms. I am still trying to list these combinations for myself. I would want to cross-reference technologies such as Quartz and ClearType with headings such as OS rendering engine, browser rendering engine, result of combination (overrides, any ignored font data).
- User settings in various places (browser preferences, OS preferences) can modify how and when the rendering engines interact with font files. Windows users can turn ClearType on or off. Users can turn antialiasing off altogether. Certain preferences can limit the size at which antialiasing is applied. Listing these variables is another item on my to-do list.
- Finally, there are the physical qualities of a user’s hardware, such as the kind of monitor they use, its resolution, whether they run it at native resolution or not, and their settings for color and luminosity.
Steps four through six are important and must not be overlooked. These factors may be the bane of type designers—especially independent shops. In the eyes of a new audience that will judge typeface quality by on-screen rendering alone, the way a typeface looks across different operating systems and browsers is critical.
Without getting into specifics (let’s save them for the discussion forum), the possible rendering algorithm combinations most often conclude in one of two ways: 1) the rendering engine ignores hints from type designers and does its own thing, remaining as true as can be to typeface design, usually with a good-looking result (this is Apple); or 2) the rendering engine relies upon complex hints from type designers, tries to use that information for ideal readability, and only looks good if the type is designed and hinted to suit this aim (this is Microsoft).
What can type designers do? Well, three things. They can prepare their typefaces to look good across different setups (even though it’s quite difficult and time consuming), they can wage a campaign for type rendering standards, or they can lose business. These are awful options.
Should type designers decide upon something like a Type Standards Project, however, I’m sure they would find skilled advocates and passionate allies on this side of the shopping cart.
What this means for web designers#section8
Already we have read about some roles web designers can play. We must move past web typography’s stigma of subordination by embracing realistic expectations for the appearance of web type and, if type designers think it worthy, we might once again bring change to a situation (typeface rendering on screens) in which standards would help.
Meanwhile, we have to make sure type looks good in our sites today.
If we run our favorite typeface through a copy of Web Font Specimen, test it across browsers, and we like how it looks, then great! That’s the typeface we will use. But what if we don’t like the way it looks? What do we do next? What are our options?
If your type renders poorly#section9
If we (and our visitors) are lucky, we might be able to look for a different typeface that does render well on screen. Despite the foreboding aspects of type design in this emerging market, thoroughly-hinted typefaces already exist that render very well in different situations—and more are on the way. For though many type designers will be disadvantaged by not having the experience or resources to augment their work with fine-tuned hinting, many others will thrive.
Disappointing as it might be at times to have to choose a typeface other than the one we seek, at other times it could be devastating. If your project is entirely dependent on the use of a particular typeface, such as when following brand-based guidelines, we may still be stuck with replacement hacks.
Unless something changes about how many typefaces are rendered across operating systems and browsers—whether that change comes from rendering agents that accept standards of some kind, or from a greater selection of thoroughly-hinted typefaces—these are the realistic choices many of us will face when we decide to use real fonts with
- use some kind of conditional logic to serve different typefaces to different visitors,
- allow our type to render in an unsatisfactory way for some visitors, and
- continue using replacement techniques.
Go forth and spec type#section10
To make change, the best thing we can do is argue for a better way by first understanding the challenges we face. To see how typefaces will look on the web, we just need a good specimen. I hope this article and Web Font Specimen make these activities easier and more fun for you, and that you find something of value here and use it to our collective advantage—for the betterment of typographic style and practice.