Type Rendering Mix

December 18, 2013

At Typekit we care a great deal about how type renders on screens. We work hard to apply our research and knowledge to the fonts we serve, but ultimately, there are some differences in how each operating system and browser renders fonts.


Typekit’s Tim Brown and Bram Stein have created a JavaScript library to help tackle the issue of inconsistent browser text rendering. Type Rendering Mix lets you apply CSS based on the text rendering engine and antialiasing method your browser is using. It does this by adding two classes to your HTML element: one for the text rendering engine and the other for the antialiasing method.

  <html class="tr-coretext tr-aa-subpixel">

Using these classes, you can (for example) decrease the font weight for the OS X Core Text rendering engine, which renders text heavier than other text rendering engines.

Above: Rooney Sans Regular in Chrome on OS X (left) and Windows 7 (right); note that OS X renders text heavier than Windows 7. Below: Rooney Sans Light in Chrome on OS X (left) and Regular in Chrome on Windows 7 (right).

By adjusting the font-weight only for browsers that use the Core Text rendering engine, we create a more consistent experience overall:

html {
  font-family: "rooney-sans", sans-serif;
  font-weight: 400;

html.tr-coretext {
  font-weight: 300;

Type Rendering Mix can also be used to display a different font based on the text rendering engine, or fall back to one of the core web fonts. See the Type Rendering Mix website for more documentation and examples.

If you’re interested in learning more about the nuances of type rendering, start by reading our Type Rendering series. We cover the differences in type rendering across operating systems, web browsers, fonts, and more.

We look forward to hearing how Type Rendering Mix helps you with your work. If you have any questions or feedback, comment here or get in touch over Twitter with Tim and Bram.

When it comes to type rendering on the web, there’s not much web designers can do. The way fonts appear on screen is mostly due to operating systems, browsers, typeface designs, font files, and how those font files are (or are not) augmented with instructions for the most unforgiving rendering scenarios. But in some cases, CSS properties can affect how type looks.

Note: the following screenshots reflect rendering in Safari 5 on Mac OS 10.6, unless otherwise noted.

Font size

Six differently-sized lowercase a characters, rendered in Windows GDI with ClearType and resized to show how resolution and grid fit change their shapes.
A slight change in font-size can mean a very different looking typeface.

First of all, there’s CSS font-size. Rasterizing a typeface’s vector outlines at sizes realistic for today’s screens means that each letter is represented by only a handful of pixels. This means a slight difference in type size can result in a very different looking typeface.


CSS color is another factor. Varying contrast between text color and background color can significantly change how type looks. Lower contrast means that antialiasing appears more subtle — the graded steps from foreground (type color) to background are less dramatic.

Low contrast. Hover for high contrast.

Light-on-dark text. Hover for dark-on-light.

Light-on-dark text tends to look thicker than dark-on-light (see also Shawn Blanc᾿s research on this topic), so lower contrast makes an even bigger difference in these cases. Keep in mind that too little contrast can cause problems for vision-impaired readers. Jonathan Snook’s Colour Contrast Check tool checks foreground and background color for WCAG compliance.

WebKit font-smoothing

The vendor-prefixed property -webkit-font-smoothing allows designers to specify one of three options: subpixel-antialiased (the default), antialiased, or none. Tim Van Damme has pointed out that the “antialiased” value tends to make text look thinner in Safari for Mac, and there was much rejoicing among designers who had previously used unrelated properties like text-shadow to make text look less bulky.

Other folks have questioned the use of -webkit-font-smoothing as a means of thinning text, even though it’s a prefix and not a posthack. Christoph Zillgens argues that diagonal strokes suffer when subpixel-antialaising is diabled, and Dmitry Fadeyev says small text is less sharp.


Finally, and perhaps obviously, type rendering suffers when text is rotated. CSS3 2D transforms, as Andy Clarke recently explained in a guest post for Typekit, allow designers to rotate elements; while this may achieve the intended result graphically, non-horizontal type is a veritable rendering wilderness. Thankfully, effects like this are less apparent on high-resolution screens.

Screenshot of text rotated at 90 degrees, image rotated back to horizontal.

Screenshot of text rotated at 45 degrees, image rotated back to horizontal.

Screenshot of text rotated at 45 degrees, image rotated back to horizontal (in Mobile Safari).

So: as a web designer, font rendering is mostly out of your hands. But it’s important to remember that certain styles within your control can have an effect. When testing, keep in mind that different styles for contrast, size, color, and rotation can result in significant differences.

This is our seventh and final post in an ongoing series about type rendering on the web. Read the first, second, third, fourth, fifth, and sixth posts.

We’ve done a lot of research on type rendering, all of which has helped us understand why text looks the way it does on the web, and we hope you’ve enjoyed learning with us. Let’s review everything so far, and then look at a selection of fonts we trust to render well.

Type rendering is the product of many layers of technology. Operating systems, web browsers, font smoothing preferences, font files and outlines, hinting, and type design philosophy: All of these play a role in translating the beautifully drawn shapes of our favorite typefaces into pixellated screen text. So the next time you see a web font that looks excellent (or awful), consider the mix of responsible technologies at play.

No one way of rendering is “correct.” Users, as well as designers, have preferences and comfort zones when it comes to reading on screen. Some people believe this is a matter of familiarity — that we read best what we read most — and there’s no denying that the introduction of an unfamiliar rendering style can be met with resistance, even if that style is popular elsewhere.

Consider the debut of Safari for Windows — a marginal case we didn’t mention in the post about web browsers, but an intriguing bit of history. In that early version of the browser, Apple circumvented Windows OS text rendering engines by including its own OS X-style rendering directly within Safari. But Windows users didn’t like it: to their eyes, it looked thick, blurry, and unlike any other text on their operating system. While it remains an option, it’s now disabled by default.

A font’s rendering is mostly about its design intentions. The way a font looks on screen has as much — or more — to do with how it was designed to be used as it has to do with a technical preparation like hinting. Low contrast, open counters, and simple outline geometry are critical to a web font’s performance at low resolution — say, for paragraph text. But these same features make for odd-looking headline type.

Hinting is arduous, expensive, and only matters for a dwindling population of web users. Hinting, as you may recall, helps a font’s vector outlines conform to the pixel grid, and can involve anything from minor adjustments to size-specific, pixel precise instructions.

As Windows browsers begin to adopt Directwrite — which relies on TrueType instructions much less than previous Windows rendering engines — and screen resolution increases, the need for hinting is waning. Although the fruit of these advancements is a long way off, we can expect font rendering at all sizes to naturally improve. Meanwhile, we should heap praise on foundries who invest in hinting despite its shelf life.

Fonts that render well

Typekit users know that we regularly update the fonts in our library whenever our foundry partners release improvements. Today, we’ve also updated our lists of Paragraph and Headline fonts based on everything that we’ve learned and discussed in this series of blog posts.

From left to right: Minion Pro, Myriad Pro, DejaRip, FF Meta Serif Web Pro, and FF Dagny Web Pro

All of the fonts tagged Paragraph have been manually hinted to look great on screen at text sizes in every major browser/OS mix. Use these recommendations to make informed decisions about how well a font will render, knowing that they are backed up by Typekit’s font diagnostic tools.

Type rendering on the web is the result of many factors, and understanding these factors is the first step toward improving the way our web projects look, and read, on screen. While this series is concluding, we will continue to research new developments in type rendering, and share what we learn along the way. And as we look to expand Typekit’s library, we are paying careful attention to rendering quality and working closely with our foundry partners to ensure that their fonts meet our — and your — high standards.

This is our sixth post in an ongoing series about type rendering on the web. Read the first, second, third, fourth, fifth, and final posts.

As Tim Brown explained in the previous post on font formats, glyphs in web fonts are stored as Bézier curves. The shapes are drawn as outlines that consist of nodes on the contour and so-called handles, which help control the exact shape of the curves. Since the contours are stored as abstract mathematical formulas, they are infinitely smooth and precise. As such, they can be scaled to any size.

Letter o shown as stored in font, and overlaid with grid
Glyphs are stored as Bézier curves but need to be rasterized for output.

On screen, however, the shapes have to be translated into pixels in a more or less coarse grid. In font technology, this resolution is expressed in ppem, which stands for “pixels per em,” and is exactly the same as the font size in pixels that you specify in CSS.

The simplest way to rasterize a letter would be to make the pixels black whenever the center of the pixel falls inside the shape. Unfortunately, this means that if part of the letter accidentally catches too many or too few pixels, the characters can become ugly or even unreadable. Missing pixels can pose as much of a problem as having too many.

In the unhinted example below, the left side of the letter happens to fall on two rows of pixels, whereas, by coincidence, the right side of the letter falls on only one row. As a result, our lowercase “o” is lopsided. In the worst case scenario, you can end up with dropouts, where the thinner parts of a letter fail to fall on any pixels at all and so disappear entirely.

Letter o with rasterized bitmap, hinted and unhinted
Unhinted (left) and hinted (right) letter at ppem 17.

This is where hinting steps in. TrueType hinting — sometimes more correctly called instructions — bends the contour of the letter into a slightly different shape before it is rasterized. As a first step, this typically involves snapping the outline to the grid, as indicated by the blue arrows in the figure above. The top and bottom of the letter are linked to the gray alignment zones, which help control at which sizes the round letters such as the o “stick out” above and below the others.

Furthermore, we want to make sure that the stem weights are representative of the original when rasterized. Individually aligning the nodes to the grid would not achieve that; we need to link pairs of associated nodes, as shown by the yellow “R” symbols. These links control the distance between the two nodes — in other words, the stem weight. Categorizing the stems makes sure they are consistent across all glyphs in the font. In the above example, the horizontal stems are assigned to the “LC” class, which includes all comparable lowercase stems.

The smart thing about this kind of hinting is that it still works if the ppem size is changed, for example from 17 to 18.

Hinted letter o with bitmap, showing two options for the horizontal stroke weight
Hinted letters at ppem 18, with different stem settings.

At some sizes the most appropriate stem thickness is debatable. In the above example, one has to choose between somewhat too thick or too thin; these are essentially design decisions and as such require a good understanding of the typeface and its stylistic character.

Note that so far, the hinting instructions that we’ve shown are not specific to a particular font size. TrueType hinting allows for specific tweaks at only one particular ppem size if necessary. This so-called delta hinting is a tedious process and is often promoted as a sign of font quality. However, it is not necessarily a sign of good hinting — if the right strategy is applied then general hinting can work well at all sizes and delta hints are unnecessary.

Hinted letters a and s with visualized TrueType instructions
Some letters require complex hinting.

Finding a good hinting strategy can be tricky at times. Some more complex letters can require special attention, and design-related questions arise: do we want to keep the black strokes consistent, or should we preserve the white inner space? In extra bold fonts such as the “s” above, one might instead choose to preserve the relationship between the black and white parts of the letter. The interplay of black and white is at the very heart of type design (and, likewise, of reading).

In the next and final post in this series, Tim Brown returns to look at what’s ahead: now that we’ve surveyed the current landscape of type rendering, what do we have to look forward to?

Avatar for Tim Ahrens

The newest member of Typekit, Tim Ahrens is a type designer and architect who runs the London-based studio Just Another Foundry. He designed FacitWeb specifically for screen display.

This is our fifth post in an ongoing series about type rendering on the web. Read the first, second, third, fourth, sixth, and final posts.

Whether a typeface has been designed or adapted for screen use significantly influences how it will look on the web. Of equal significance to type rendering are fonts’ technical composure: a typeface’s outline and hinting instructions (or lack thereof) can affect screen rendering. In this post we’ll talk about font outlines, as well as how file formats and browser compatibility affect the rendered text we see on websites. Then in our next post we’ll look at hinting.

Font files contain a typeface’s vector outlines in one of two flavors: PostScript (PS) or TrueType (TT). Miguel Sousa from Adobe recently explained in detail the benefits of PS-based outlines over TT-based outlines. At the most basic level, the difference between these two outline formats is a matter of mathematics (cubic vs. quadratic Bézier curves). But a font’s existence as one kind of outline or another can affect its file format, and not all web browsers support all file formats. Buckle up, the next few paragraphs are going to be turbulent.

No single font file format works in all web browsers (yet), so Typekit serves the most appropriate format to each browser: the emerging W3C standard WOFF (Web Open Font Format) wherever possible, Embedded OpenType (EOT) to Internet Explorer (it’s the only format IE8 and earlier will accept), and either raw OpenType (OTF) or raw TrueType (TTF) everywhere else.1 2

File format Font outlines Browsers
WOFF PS or TT curves Firefox 3.6+, Chrome 6+
EOT PS or TT curves* IE6–8 *PS curves: IE8 only
Raw OTF/TTF PS or TT curves (OTF), TT curves (TTF) All other browsers

On top of that, not all font file formats support both kinds of font outline. OTF files and WOFF files can contain either TT or PS outlines; TTF files can only contain TT outlines; and for EOT files it depends on which version of Internet Explorer is being used. We can sometimes circumvent these restrictions or achieve better results by converting from one kind of font outline to the other.

TT outlines are made of quadratic curves and PS outlines are made of cubic curves, so it’s mathematically possible to convert TT to PS without any data loss. However, most type designers prefer to draw PS curves, so most of the conversion we do is PS to TT. This is a lossy process and increases file size; unfortunately, it’s something we must address because IE8 and earlier will only accept EOT files, and because EOT files in IE6 and 7 will only accept TT outlines. In order for a font with PS outlines to appear in IE7 and earlier, it must necessarily be converted to TT.

Typekit’s goal is to serve fonts with the smallest possible file size and with the original design intact. We experiment by looking at outlines in different browsers, we listen to customer feedback about which fonts render well (or don’t), and we continually iterate on our font processing pipeline to reflect our latest findings.

Then, there’s hinting. Hinting helps a fonts’ vector outlines conform to the pixel grid, and can involve anything from minor adjustments to size-specific, pixel precise instructions. As Typotheque’s Peter Bil’ak explains in his excellent article on hinting:

Hinting can control the heights and widths of a font’s uppercase and lowercase letters, the widths of its individual lines, the amount of white space around letters, the size at which uppercase letters start to use different stem-widths from lowercase letters, how the angle of italic characters changes to best fit the pixel grid, and many other extremely technical details, all on a pixel-by-pixel basis. If this sounds like a rather tedious, time-consuming activity, it is, (even for type designers, who are accustomed to tedious, time-consuming activities).

Tim Ahrens, type designer at Just Another Foundry, maker of FacitWeb, and the newest member of Typekit, will write our next post about the mechanics of hinting. In some situations, this black magic of web fonts can have a significant impact on rendered type; in other situations, it matters little — or not at all. But either way, hinting is an arduous, amazing process that deserves to be explained. When it matters, hinting is integral to a typeface’s screen appearance.

  1. 1. We currently serve SVG fonts to iOS, but will soon serve TTF thanks to this iOS update.
  2. 2. OpenType can be a confusing term — check out Ralf Hermann’s excellent disambiguation, OpenType myths explained. When I say OTF in this article, I mean .otf font files that contain either PS or TT curves. I’m not talking about OpenType features, which can be present in either .otf or .ttf files.

This is our fourth post in an ongoing series about type rendering on the web. Read the first, second, third, fifth, sixth, and final posts.

Now that we’ve talked about operating systems and browsers, it’s time to tackle the third element of all web type rendering mixes — the fonts themselves. When it comes to font files and screen rendering, there are two issues of equal importance to discuss: font file formats, which I’ll cover in our next post, and how the design philosophy of a typeface influences its rendering.

Design philosophy and the means of production

We have a tendency to think of fonts as one-size-fits-all, because that’s largely how personal computing has taught us to think. On the web, in rich email, or in a word processor, we have the ability to scale fonts to sizes that were never intended by the designers of those fonts. Historically, fonts have been designed with specific (and limited) sizes and contexts in mind. In fact, in metal type the word “font” means a particular typeface at a specific size — a “font of type” meant a drawer full of leaden letters.

Type designers, ideally focused on creating the most beautiful and meaningful forms possible, have always had to consider the means of production as they design and produce typefaces — but rarely if ever have type designs been used in such a broad array of contexts as they are today. Different media (screen/print), viewing formats (projector/laptop/phone), and rendering engines exercise type in a variety of ways, and it’s extremely difficult to prepare a typeface to handle all of these situations at once.

Ink traps, print thickening, and antialiasing, each accounted for by design.

Just as newspaper fonts are designed with ink traps to account for the spread of ink on cheap paper, and fonts for letterpress are designed with thin strokes that produce a thicker imprint, some typefaces are made to look good at low resolution on screens. But that preparation for low resolution is also a design philosophy. Fonts like these are designed to fit the pixel grid. At higher resolutions or larger sizes, where antialiasing is less critical to basic legibility, these same typefaces can be unsuitable. They can feel too open, boxy, or thick — the very same qualities that make them work well at small sizes.

FacitWeb (left) and Minion Pro (right) at 30px (above) and 12px (below).

Available on the web today, there are great typefaces coming from these two different, and valid, perspectives: typefaces designed for web use at low resolution (like FacitWeb), and typefaces not designed for web use that are being improved and rereleased for better screen rendering (like Minion Pro). Depending on the size at which one intends to set text, it’s easy to see the advantage of either approach. Type designed for low resolution looks great on screens at small sizes, and type drawn for its own sake — without low resolution antialiasing as a design philosophy — is arguably more balanced and beautiful at mid-to-large sizes.

How can we adapt the great typefaces of the pre-web era to work successfully on the web today? Our next posts will discuss the different font file formats and how those files can be improved by hinting instructions. Hinting is an arduous, time-consuming task that requires a great deal of skill, but under the right circumstances it can improve the way a font renders on the web. We’ll also look ahead to how newer rendering engines may affect font rendering in the future. Stay tuned!

This is our third post in an ongoing series about type rendering on the web. Read the first, second, fourth, fifth, sixth, and final posts.

Every great web browser has a layout engine that explicitly decides how to turn our markup, stylesheets, and scripts into living, breathing websites. Layout engines have everything to do with how our web designs are generated and visualized; however, for the specific task of type rendering, layout engines almost always defer to the operating system’s text rendering engine. This explains why type in the same web browser renders differently on different operating systems. Furthermore, browser preferences can override or change default OS font smoothing settings. Let’s look at how type rendering is affected, or not affected, by each popular web browser.

Mac OS X Browsers

We’ll kick this off the easy way. On a Mac, all web browsers use Core Text – the system default text rendering engine – and OS font smoothing settings. There are no browser preferences that affect the way type is antialiased. So, on a Mac, type looks the same no matter which browser you use.

Windows: Firefox, Chrome, Safari, Opera, and IE6

As on a Mac, all of these browsers use the system default text rendering engine and OS font smoothing settings. In general, a given font, on a given operating system installation, will render consistently in all of these browsers. As I explained in the previous post, Windows 7 and Windows Vista have ClearType sub-pixel antialiasing enabled by default, whereas Windows XP has Standard grayscale antialiasing enabled.

Windows: IE7 and 8

Internet Explorer 7 has a preference called “Always use ClearType for HTML” that overrides the default OS font smoothing setting. This preference is enabled by default, which means that users of IE7 will usually see type that is antialiased with ClearType — even if they are using Windows XP or have explicitly chosen standard font smoothing in their OS settings.

Internet Explorer 8 also has this preference, and it is also enabled by default. However, when IE8 is installed it forcibly changes the OS font smoothing setting to ClearType sub-pixel antialiasing. This means that font smoothing is affected everywhere — not just in IE8. For example, if you’re a Windows XP Firefox user who has never modified your smoothing settings – and you happen to install IE8 – you would subsequently see ClearType-antialiased text in Firefox.

Windows: IE9 and Firefox 4

Type rendering in Internet Explorer 9 is a breath of fresh air. IE9 bypasses OS font smoothing settings in favor of Microsoft’s DirectWrite text rendering engine, which makes type look incredible. It also ensures that all IE9 users will see type rendered the same way. Firefox 4 will reportedly also use DirectWrite for text rendering.

So, which browsers to test with?

But what does all this mean for the web designer? Luckily, there are only a handful of browser/OS combinations that you need to check in order to have a thorough grasp on the way a particular font renders on the web:

  • Any Mac browser
  • IE9
  • IE8 with ClearType enabled
  • IE6 with Standard antialiasing enabled
  • Firefox 4

And that’s it. This list of browsers for testing is based on out-of-the-box browser/OS installations, where no settings or preferences have been changed by a user. This out-of-the-box approach is how screenshots from Typekit’s own Browser Samples are taken, and reflects what you’ll see in the samples from many screenshot services. If you have your own testing environment, you may find that you have some flexibility in choosing browsers for testing — because it’s really the text rendering engines and OS font smoothing preferences that we’re trying to account for.

And oh yeah, the fonts

Earlier in this post, you’ll notice I was careful to use the phrase, “a given font.” All of what I’ve described so far — about operating systems, text rendering engines, font smoothing settings, browsers, and browser preferences — is true, but it does not account for the font file itself.

Our next two posts will explain how font files factor into all of this. After that, we’ll round things up by reviewing some specific OS / browser / font rendering mixes, and we’ll talk about what aspects of these mixes we can improve. We’ll also talk about how CSS properties can affect type rendering. Stay tuned!

This is our second post in an ongoing series about type rendering on the web. Read the first, third, fourth, fifth, sixth, and final posts.

As we dig into type rendering on the web, we’ll begin by looking at text rendering engines. We are all familiar with operating systems like Windows and Mac OS X, but within each OS are smaller, specialized components available for use by applications like web browsers. APIs such as Core Text on Mac OS X, and DirectWrite and GDI on Windows, are examples of these components and are responsible for rasterizing fonts’ vector outlines. Let’s examine screenshots of web type as rendered by each of these APIs, and talk about the application independence of rendering engines.

The screenshots below were taken by visiting this test page that features two Typekit fonts, FacitWeb and Minion Pro. FacitWeb, occupying the top row of each screenshot, has a 120px capital R, a 21px subhead, and 12px text. Minion Pro, across the bottom of each screenshot, has a 130px capital R, a 24px subhead, and 14px text. The detail images are zoomed to 300%.

Core Text

Core Text is a rendering engine available on Mac OS X and iOS. In fact, it’s part of a suite of APIs called Core Foundation that underlies much of the slick interaction and glossiness for which Apple user interfaces are loved. It’s no surprise that Apple-rendered text reflects this same slickness, some would argue to the detriment of legibility. Core Text type tends to respect a typeface’s designed shape, which essentially means thicker letters (rather than pixel grid strictness). This can make letters, as well as spaces within and among letters, seem blurry at paragraph sizes. However, at very large sizes Core Text type looks natural and smooth. Part of its success at large sizes has to do with y-direction antialiasing, which is especially noticeable in the subtle curves of large letters — compare the detail images of Core Text’s capital R with those of GDI, which does not antialias vertically.

Above: Core Text rendering of FacitWeb (above) and Minion Pro (below).

Look closely at the detail images and you’ll notice that some pixels are tinted with color. This is called sub-pixel antialiasing, which uses the vertically-oriented thirds of red, green, and blue light within each pixel of an LCD screen to effectively triple the horizontal resolution of text. At reading distance from the screen, our eyes cease to notice colored sub-pixels and we instead see sharper text than we otherwise would. Or at least, that’s the idea. For some folks, the sub-pixels are always noticeable and this amounts to an annoying color fringe effect on the edges of letters.


If Apple sub-pixel antialiased text is true to typeface design at the expense of some blurriness, Microsoft sub-pixel antialiased text is crisp and legible at the expense of style (and at the cost of many font production hours, but we’ll get to that in a future post). As Joel Spolsky once noted, there is a philosophical difference between the two companies’ approaches, and this is evident as we compare Apple’s Core Text to Microsoft’s DirectWrite.

Above: DirectWrite rendering of FacitWeb (above) and Minion Pro (below).

DirectWrite, the latest and greatest text rendering engine for Windows, is available on Windows 7 and Windows Vista. It is markedly clearer, smoother, and has less intense color fringing than Core Text and older Windows text rendering engines. As with Core Text, there is y-direction antialiasing for smooth curves. (Compare, however, the bottom edges of paragraph text in DirectWrite with those of Core Text; Both engines use y-direction antialiasing, but Core Text’s closer adherence to actual glyph outlines translates to subtle antialiasing smudges below the baseline. Microsoft engines clean this up.) And as with Core Text, sub-pixels in DirectWrite are used not only to antialias text but also to space letters horizontally, which means letters can sit more naturally next to one another than in Microsoft’s older text rendering engine, GDI.

Graphics Device Interface (GDI)

The GDI text rendering engine, available on Windows 7, Windows Vista, and Windows XP, actually comes in two flavors: GDI and GDI+. GDI+ is superior and has been included with Windows since XP, so when I talk about GDI here I’m actually referring to GDI+. Another bit of disambiguation: text rendering engines like GDI and DirectWrite both use, but are paradigmatically different than, the sub-pixel antialiasing algorithm ClearType. Antialiasing is just one function of text rendering engines, which are also responsible for Unicode mapping, OpenType features, and integration with other APIs like web browser layout engines.

In keeping with another philosophical difference between Apple and Microsoft, Windows operating systems provide users with several antialiasing preferences from which to choose: ClearType (sub-pixel antialiasing), Standard (grayscale antialiasing), or no antialiasing (black and white text without any smoothness). By default, ClearType is enabled in Windows 7 and Windows Vista, and Standard is enabled in Windows XP. We’ll revisit these preferences in our next post about web browsers, some of which have their own font smoothing options.

GDI with ClearType antialiasing enabled

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with ClearType enabled.

As you see here, and as most Windows 7 and Windows Vista users see when they browse the web, GDI-rendered type with ClearType enabled – unlike DirectWrite or Core Text – does not antialias text in the y-direction. Note the abrupt, staircase-like curves in the capital R detail. This text also exhibits sub-pixel antialiasing with significant color fringing, perhaps because this early breed of the ClearType algorithm had yet to be refined.

There are different versions of ClearType, just as there are different Windows rendering engines and different web browsers. These nested components evolve independently, but the latest version of each may not be present in a given web browsing experience. For example, a version of ClearType with y-direction antialiasing, similar to what we see in DirectWrite, was available via another Windows API called Windows Presentation Foundation (WPF). But because no version of Internet Explorer made proper use of WPF, web text viewed with a Windows browser has traditionally lacked y-direction antialiasing.

GDI with Standard antialiasing enabled

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with Standard antialiasing.

You wouldn’t know it by our survey of text rendering engines thus far, but there was a time when sub-pixel antialiasing was not the most common means of smoothing fonts on screens. Windows Standard antialiasing is in good ol’ grayscale. This is how most Windows XP users see type on the web (unless they browse with Internet Explorer 7 or 8, but we’ll get to that later!), and how most users with CRT monitors see type as well (LCD-based sub-pixel antialiasing doesn’t work when there are no sub-pixels).

Grayscale antialiasing adjusts whole pixels at once, doing its best to approximate the partial presence of a letterform by showing a solid gray representation of the two-dimensional area consumed by the shape’s overlap upon a given pixel. Grayscale text is not sharp enough to be very legible and, combined with Windows’ philosophical preference for snapping to pixel edges, does not adhere to the design of a particular typeface very well.

GDI with no antialiasing

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with no antialiasing.

While rare because it is not the default choice on any modern Windows OS, aliased text (that is, text without any kind of antialiasing) is what some folks see as they read web text. The most common reasons type is rendered this way are because the user (or computer’s administrator) prefers this style of text rendering and has adjusted the OS antialiasing settings, or because a particular setting within the font file has explicitly disabled antialiasing for the specific font size being used. We’ll talk more about this setting in a future post about font files.

Screenshot review

Here again are each of the screenshots. For extra fun, try opening each image in a new tab and flipping quickly among them.

Above: Core Text rendering of FacitWeb (above) and Minion Pro (below).

Above: DirectWrite rendering of FacitWeb (above) and Minion Pro (below).

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with ClearType enabled.

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with Standard antialiasing.

Above: GDI rendering of FacitWeb (above) and Minion Pro (below) with no antialiasing.

In summary, most people reading text on the web view type in one of these five ways. Mac OS X users see Core Text, Windows 7 and Windows Vista users see either DirectWrite or GDI, and Windows XP users see GDI. For now, I have not included details about Linux or Android OS. (If you have any good references for how web browsers on these platforms render text, please link them up in the comments!) But as we will see in future posts, preferences, web browsers, font formats, and CSS properties may each affect the way type is rendered on the web.

Type rendering on the web

October 5, 2010

This is our first post in an ongoing series about type rendering on the web. Read the second, third, fourth, fifth, sixth, and final posts.

Back when web fonts were in their infancy, I asked typophiles to help me understand why fonts look the way they do in web browsers. A year and a half later, with their help, advice from a few expert type technicians, and lots of research here at Typekit, we’re starting to fully understand type rendering on the web.

The translation of a font’s outlines into pixellated text of varying quality, consistency, and sharpness is not straightforward. It involves both a font and a rendering engine, and only so much can be controlled by type designers and web designers.

Proxima Nova lowercase “a,” as rendered by three different browser/OS mixes at 16px.

Each operating system contains a text rendering engine — sometimes multiple engines from which to choose. And each browser controls which of those rendering engines is used. So on the same OS, two browsers can produce text with very different appearances because they use different rendering engines. On top of that, often the rendering engines differ between different versions of the OS and different versions of the browser. Additionally, default font-smoothing settings vary by OS and OS version, and can be overridden by users’ browser preferences.

On the font file side, screen rendering depends on how the letterforms were drawn, the format of the font file, and the amount of effort put forth by the font’s producers to hint or instruct its shapes in such a way that they lay nicely on a pixel grid. “Hinting” — often cited as the reason a typeface looks good or bad on screens — is only one factor (and occasionally a non-factor) in a given type rendering mix.

Over the next few weeks I will be writing to share in detail what we have learned about font outlines, how those outlines are prepared for rasterization on screens, and how font files, browsers, operating systems, font smoothing preferences, and CSS properties combine to produce rendering mixes that result in the type we all see as we browse the web. If the conditions are right, web font rendering can be spectacular. Together, we can figure out exactly what steps we need to take to get there.

If you have any questions you would like answered in these posts, please share them in the comments. There’s so much to know and to talk about, and we’re all learning as we go. No questions are too big or too small.

UPDATE: Read the second article in this series on Type Rendering and operating systems.