A Closer Look At Font Rendering

Advertisement

The Web font revolution that started around two years ago has brought up a topic that many of us had merrily ignored for many years: font rendering. The newfound freedom Web fonts are giving us brings along new challenges. Choosing and using a font is not merely a stylistic issue, and it’s worth having a look at how the technology comes into play.

While we cannot change which browser and OS our website visitors use, understanding why fonts look the way they do helps us make websites that are successful and comfortable to read in every scenario. Until recently, there were only a small handful of “Web safe” fonts we could use. While offering little variety (or means of expression), these fonts were very well-crafted and specifically adjusted—or even developed—for the screen, so there was little to worry about in terms of display quality.

Now that we have a great choice of fonts that can be used on websites, it becomes clear that the translation of a design into pixels is not something that happens naturally or consistently. OS makers apply different strategies to render how typefaces are displayed, and these have evolved greatly over time (and still continue to do so). As we now look closer at fonts on screen more than ever before, we realize that the rendering of these glyphs can differ significantly between systems and font formats. What’s more, it has become clear that even well-designed fonts may not look right on Windows if they are missing one crucial added ingredient: hinting.

This article presents the mechanisms of type rendering, how they were developed, and how and why they are applied by the various operating systems and browsers—so that when it comes time to choose a font for your next project, you know what to look out for to ensure the quality of the typography is consistently high.

Rendering Strategies

Ideal shape, black-and-white and grayscale rendering
Ideal shape, black-and-white and grayscale rendering

Rasterization

In digital type, characters are designed as abstract drawings. When a text is displayed on screen, this very precise, ideal shape needs to be expressed with a more or less coarse grid of pixels. As screens turned from mere preview devices for printing output into the actual medium we read in, more and more sophisticated rendering methods were developed in order to make type on the screen easy and pleasant to read.

Black And White Rendering

The earliest method of expressing letter shapes was using black and white pixels, sometimes referred to as bi-level rendering. Printers are still based on this principle, and thanks to their high-resolution, the result is a very good representation of the design. On screen, however, the small number of available pixels does not transport the subtleties of the drawn shapes very well. And although we might not be able to see the individual pixels, the steps found in round contours are noticeable.

Grayscale Rendering

In the mid-1990′s, operating systems started employing a very smart idea. Although screens have a rather low resolution, they can control the brightness of each pixel. This allows more information to be brought into the rasterized image.

In grayscale rendering, a pixel that is on the border of the original shape becomes gray, its brightness depending on how much it is covered by the ideal black shape. As a result, the contour appears much smoother, and design details are represented. The type on screen is no longer merely about being legible—it has its own character and style.

This principle—also called antialiasing—is the same that is used when photos are resampled to a lower resolution. Our eyes and brain interpret the information contained within the gray pixels and translate it back into sharp contours, so what we perceive is fairly close to the original shape. A similar effect is at work when a relatively coarse newspaper image that can appear nicely shaded if we hold it far enough away (or similarly, in the art of Chuck Close). Recently, Gary Andrew Clarke took this to the extremes with his “Art Remixed1” Series.

Subpixel Rendering

Apparently colored pixels increase the resolution
Apparently colored pixels increase the resolution.

The third generation of rendering technology is characterized by apparently colored pixels. If we take a screenshot and the edges appear red and blue when enlarged, then we know that we are looking at subpixel rendering.

On LCD screens, the red, green and blue subpixels that control the color and brightness of the pixel are located side-by-side. Since they are so small, we don’t perceive them as individual colored dots. Having a closer look at the “red” pixel marked by the white dot reveals the strategy: all subpixels are switched on or off individually, and if the rightmost subpixel of the “whitespace” happens to be a red one, then the corresponding full pixel is technically red.

Subpixel rendering on an LCD screen
Subpixel rendering on an LCD screen.

The benefits of this technique become clear if we desaturate the image. Compared to plain grayscale rendering, the resolution has tripled in horizontal direction. The position and the weight of vertical stems can be reflected even more precisely, and the text becomes crisper.

Current Implementations

For the display of text, almost all browsers rely on system rasterizers. When looking at Web font rendering, the key distinction we have to make is the operating system. However, there are differences between the browsers in terms of the support given to kerning and ligatures, as well as the application of underline position and thickness, so we cannot expect perfectly identical rendering in all browsers (even on one platform). What’s more, on Windows, the browser can have the font rendered by either of the system technologies—GDI or DirectWrite.

Before we look at these in detail, lets first get an overview of where each one is to be used:

Rendering modes used by Windows browsers
Rendering modes used by Windows browsers.

Windows

On Windows, the font format has a significant impact on the rendering. The crucial difference is between PostScript-based and TrueType-based fonts, and not the way these are brought into the browser—JavaScript vs. pure CSS, raw fonts vs. “real” Web fonts, etc. We will see identical rendering as long as the underlying font is the same.

File formats can give us a clue as to what underlying rendering technology is being used, although it’s best that one doesn’t completely rely on the naming conventions. For example, EOT and .ttf files will always contain TrueType, whereas .otf fonts are typically PostScript-based. But then there’s the wrapped format WOFF, which can contain either “flavor” of font format. So we don’t know which one it contains (and therefore, what kind of rendering may be used), just by looking at the file name. Unless you’re using EOT or .ttf files, and can be sure it’s a TrueType, more investigation when purchasing fonts is always recommended.

TrueType and PostScript fonts differ in the mathematics used to describe curves—something that rasterizers don’t care about too much—it only makes a difference for the type designer when editing the glyph shapes. What is more relevant is the different approach to hinting. PostScript fonts only contain abstract information on the location of various elements of each letter (and rely on a smart rasterizer to make sense of this), whereas TrueType fonts include very specific low-level instructions that directly control the rendering process. Curiously, however, the effective differences in rendering are not due to these differences in concept, but rather stem from Microsoft initially deciding to apply their new rendering engine only to TrueType fonts.

Windows: TrueType Fonts

TrueType font rendering with Windows grayscale
TrueType font rendering with Windows grayscale
TrueType font rendering with Windows grayscale.

On Windows XP, text is rendered as grayscale by many browsers. Although not as crisp as the subpixel rendering used by Mac OS, the letters are nicely smoothed and look great in large sizes.

TrueType font rendering with Windows GDI ClearType
TrueType font rendering with Windows GDI ClearType
TrueType font rendering with Windows GDI ClearType.

ClearType is Microsoft’s take on subpixel rendering. It was first made available for GDI, the classic Windows API. Although available in Windows XP, it is not used by all browsers. In Windows 7 and Vista, ClearType is the default, which makes it the most widely used rendering technology (if we were to consider all internet users). However, it is important to note that this applies only to TrueType-based Web fonts—GDI-ClearType is not applied to PostScript-based fonts.

One curious property of this rendering technology is that along with adopting the advantages of subpixel rendering in horizontal direction, Microsoft gave up smoothing in vertical direction entirely. So ClearType is effectively a hybrid of subpixel and black-and-white rendering. This results in steps within the contour, which is particularly noticeable in large sizes. These jaggies at the top and bottom of the curves are unpleasant, but unavoidable—even the best hinting cannot make them disappear.

For type in large sizes, ClearType is a step backwards in rendering quality. The gains in horizontal precision are not significant, while the rough contours spoil the overall result.

TrueType font rendering with DirectWrite
TrueType font rendering with DirectWrite
TrueType font rendering with DirectWrite.

The future is bright, at least in terms of Windows font rendering. In DirectWrite (the successor of GDI), Microsoft added vertical smoothing to ClearType. This new rendering mode (so far used by Internet Explorer 9), gives us smooth and precise rendering in all sizes. The main difference to Mac OS that remains is that it still tries to align contours to full pixel heights, which leads to even better rendering given that the font is well-hinted. What’s more, DirectWrite allows for subpixel positioning, which gives the characters exactly the spacing that they have been designed with, improving the overall rhythm and evenness of the texture.

Windows: PostScript Fonts

PostScript font rendering with GDI grayscale
PostScript font rendering with GDI grayscale
PostScript font rendering with GDI grayscale.

In GDI-based browsers, PostScript-based Web fonts are displayed in grayscale. Unlike the prevalent GDI-ClearType, this gives smooth contours. And unlike TrueType hints, PostScript hinting is easier to create, even automatically.

PostScript font rendering with DirectWrite
PostScript font rendering with DirectWrite
PostScript font rendering with DirectWrite.

DirectWrite not only gives smoother outlines, it also applies subpixel rendering to PostScript fonts. Unlike TrueType rendering, however, it allows for more gray pixels in order to reflect stroke weights more realistically. That makes it well-balanced, and similar to Mac OS rendering.

At some point in the future—browser makers and users will not switch as quickly as we wish—DirectWrite will succeed the older Windows rendering methods, and we will indeed be spoilt for choice between TrueType- and PostScript-based Web fonts.

Windows: Unhinted Fonts

Unhinted font rendered with grayscale
Unhinted font rendered with grayscale
Unhinted font rendered with grayscale.

In the old Windows grayscale mode, completely unhinted fonts look surprisingly good. Since the font does not “align itself” to full pixels via hinting, and the rasterizer does not enforce this either, we have a rendering that is similar to that of iOS. Unfortunately, unhinted fonts are currently not an option, as the next example shows:

Unhinted TrueType font in GDI-ClearType rendering
Unhinted TrueType font in GDI-ClearType rendering
Unhinted TrueType font in GDI-ClearType rendering.

As noted in many discussions on Web font rendering quality, GDI-ClearType is extremely dependent on good hinting. Horizontal strokes have to be precisely defined by means of hinting, otherwise they might be rendered in an inappropriate thickness. Even in larger sizes, hinting is crucial. Unhinted fonts will show “warts” sticking out where contours are not correctly aligned to the pixel grid, like in the example above.

Unhinted font rendered with DirectWrite
Unhinted font rendered with DirectWrite
Unhinted font rendered with DirectWrite.

In DirectWrite, unhinted PostScript and TrueType-based Web fonts show virtually the same rendering. Text fonts of either flavor will still need good hinting in order to keep the strokes crisp and consistent. Display fonts may even get away with sloppy or no hinting, since this does not show much in large sizes.

Mac OS X

Font rendering in Mac OS X
Font rendering in Mac OS X
Font rendering in Mac OS X.

On Mac OS, all browsers use the Quartz rendering engine. TrueType and PostScript fonts are rendered in exactly the same way, since hinting—the biggest conceptual difference between the two formats—is ignored. The subpixel rendering on Mac OS is very robust, so this platform is typically the one we need to worry about the least. The rasterizer doesn’t try to understand the strokes and features that make up a font, as everything is represented by more or less dark pixels. Since the letter shapes are not interpreted, they cannot be misinterpreted. Quartz rendering is reliable because it doesn’t try to be smart. As a side note, Apple does seem to apply some subtle automagic to enhance the rendering, but this is entirely undocumented and beyond our control.

In some cases, however, this leads to less-than-ideal results. In the above example, the large size “T” has a fuzzy gray row of pixels on top because the theoretical height is not a full pixel value, and Mac OS does not force its alignment. Unfortunately this cannot be controlled by the font maker. However, the blurriness occurs only in certain type sizes. So typically, choosing a slightly different font size fixes the problem. With a bit of trial-and-error, one can find a type size that looks comfortable and crisp.

Another difficult-to-control phenomenon is that on the Mac, type tends to be rendered too heavy. This difference is most noticeable in text sizes, where the same font can look a bit “sticky” on Mac OS while appearing almost underweight on Windows.

iOS

Font rendering in iOS
Font rendering in iOS
Font rendering in iOS.

The rendering on iOS follows the same principles as on Mac OS—the main difference is that it currently does not employ subpixel rendering. The reason might be that when the device is rotated, the system would have to re-think and update the rendering because the subpixels are physically oriented in a different way, and the makers wanted to minimize CPU use.

Conclusions

Website visitors use a great variety of systems and browsers. Some are not up-to-date, and sometimes it’s not even the user’s fault, but rather a company’s policy to stick with a certain setup. My personal opinion is that we should try and give them the best rendering we can, instead of blaming OS makers, or demanding users to switch to better systems.

On Mac OS and iOS, we hardly have any control over the rendering, which is acceptable (since it’s generally very reliable). One problem is that fonts generally render too heavy. Maybe some day, Web font services can improve the consistency by serving slightly heavier or lighter fonts depending on the platform.

On Windows, hinting matters—especially for TrueType-based fonts (the only Web fonts Internet Explorer 6–8 will accept). Apart from that, one significant control we have over the rendering is the choice between TrueType and PostScript. Except for very well-hinted fonts in smaller sizes, the latter is equal or superior in rendering, and easier to produce. Even though DirectWrite is making Windows rendering more pleasant, it will not remove the necessity to provide well-hinted fonts.

Practical Application: Improving Display Font Rendering

Some Web font providers (such as Typekit or Just Another Foundry), have started serving display fonts in PostScript-based formats.

JAF Domus Titling Web rendered with GDI ClearType
JAF Domus Titling Web rendered with DirectWrite
JAF Domus Titling Web rendered with Windows grayscale
JAF Domus Titling Web in Mac OS X
JAF Domus Titling in different rendering environments.

While the GDI ClearType jaggies are unavoidable for IE 6–8, all other scenarios produce nice, smooth results. This also means that we will still need fonts that have decent TT-hinting—the browser share of IE6–8 is still too big to deliver fonts that don’t at least render in a clean fashion.

Bello by Underware on Typekit
Bello—by Underware on Typekit—served as PostScript-based Web fonts (right), which gives smoother rendering than TrueType (left).

Typekit has also started to implement a hybrid strategy by serving display fonts as PostScript in order to trigger smoother rendering in Windows GDI. This requires some decisions to be made on the basis of visual judgement.

“How do you define a display font?”, you may ask, and it is indeed difficult to draw the line. Some of the foundries offer high-quality, manually hinted TrueType fonts that look great in text sizes (and it would be a pity to lose this sophistication by converting them to PostScript). Some text fonts may well be used in very large sizes. So ideally, we would have to offer them in two different formats. However, increased complexity of the UI (as well as back-end handling) have so far kept us from doing this.

Future Developments

More and more type designers are becoming aware of the technical issues that arise when fonts are used on the Web, particularly TrueType hinting. As the Web font business grows, they are willing to put some effort into screen-optimizing their fonts. In the near future, we will hopefully see a number of well-crafted new releases (or at least updates to existing fonts).

With increasing display resolutions— and more importantly, improving rasterizers—we will slowly have to worry less about the technical aspects of font rendering. GDI-based browsers will certainly be the boat anchor in this respect, so we won’t be able to use TrueType fonts that aren’t carefully hinted for yet another few years. Once this portion of Web users has become small enough, the process of TrueType hinting (which is time-consuming and requires considerable technical skills), becomes less crucial. While most Web fonts currently on the market are TrueType-flavored, I am expecting that the industry will largely switch to PostScript, which is the native format nearly all type designers work in (the fonts that are easier to produce).

Other Resources

(jvb) (ac) (il)

Note: A big thank you to our fabulous Typography editor, Alexander Charchar6, for preparing this article.

↑ Back to topShare on Twitter

Tim Ahrens is a type designer based in Berlin, where he is running Just Another Foundry with Shoko Mugikura. As a former architect, he is interested in the interplay between technology and design. He develops design software such as the Font Remix Tools and web applications like the FontFonter for FontShop International. Since 2010 he has been working as a consultant for Typekit.

  1. 1

    Really nice article, I was looking into fonts only a week ago so very useful.

    p.s intro paragraph doesn’t read correct here: ‘The newfound freedom Web fonts are giving us brings along new challenges.’

    0
  2. 2

    Terence Tuhinanshu

    April 24, 2012 5:19 pm

    Great article. I’d love for a follow up to include some tips for font designers teaching how best to use these cases, how to prepare a font for web delivery, the best principles of hinting, etc.

    8
  3. 3

    I don’t really understand why people love blurred fonts. I had to disable ClearType since it was introduced in Windows XP because I got headaches from the rainbow shadows it paints around the glyphs. And now all the webbrowsers start switching to DirectWrite including Opera 12 (currently in development and therefor missing in your comparison). The problem is, DirectWrite has a major bug when ClearType is disabled. It tries to address half pixels but since half pixels do not exist this attempt ends in a blurred mess of gray pixels. I tried to report this as a bug but the developers tend to ignore it: https://bugzilla.mozilla.org/show_bug.cgi?id=719410 As said, it’s the same bug in Firefox 4+, IE 9+ and Opera 12.

    -3
    • 4

      It’s most likely your graphics card and/or card firmware version causing the problem.

      -5
    • 5

      Smooth =/= ‘blurred’. The ultimate aim is to replicate the appearance of type on paper and hard edged, pixelated fonts are far from that. In my experience Cleartype doesn’t do a great job at this. Do you get still headaches from reading type that is rendered by Quartz?

      0
    • 6

      That bug wasn’t ignored, it was investigated and commented-on at some length. However, application developers can’t necessarily work around a fundamental shortcoming in the DirectWrite rasterizer, which seems to assume that subpixel antialiasing will be used. At least in Firefox – I’m not sure about the other browsers – you can turn off hardware acceleration and thus revert to GDI fonts if you prefer how they look without ClearType.

      0
    • 7

      Re “rainbow shadows”:
      This does not happen if your screen/OS combination is adjusted correctly. As the above photo of an LCD screen shows, the “colored” pixels of the font rendering do not lead to more pronounced color fringes than grayscale rendering (technically, even a pure black on white vertical line has a color fringe!). Have you explored the ClearType settings in the Windows Control Panel? Some screens have BGR instead of RGB, and ClearType accounts of that if it is set by the user.

      Re “half pixels do not exist”:
      You are referring to subpixel positioning, which I did not address in the article. It is not to be confused with subpixel rendering – in fact, the two are independent. You can apply subpixel rendering without subpixel positioning, or even subpixel positioning without subpixel rendering. In that sense, half pixels do exist. DirectWrite, in contrast to GDI, allows for subpixel positioning. Visually, it is undoubtedly an improvement, the only cost is CPU usage.

      1
      • 8

        Re “half pixels do exist”:

        Almost all people talking about this subject forget an very important fact. The three subpixels are not independent from each other. They are connected. There are separations between each red-green-blue triple for the sole reason to make them look like full pixels and not like independent red, green and blue pixels.

        Here is a simple test you can do for your own. In theory it should not matter if you are painting a black pixel on a white background (RGBrgbRGB with upper case letters meaning “on” and lower case letters meaning “off”) or if you are painting a red and a cyan pixel (RgbrGB) or a yellow and a blue pixel (RGbrgB). All should look like a black pixel on a white background. But surprise, it does not work, no matter if you put the red pixel left or right of the cyan pixel. Everything is far more colored compared to a real black pixel. If you don’t see a difference you probably own a very cheap, very bad monitor that paints rainbow shadows everywhere, even on black pixels.

        Subpixel rendering is a lie. What ClearType and Quartz really do is a lot of antialiasing, a lot of sophisticated hinting and only a tiny, tiny fraction of subpixel rendering. The problem with DirectWrite is: It does way to much subpixel rendering and is very bad at hinting. And it does not do any hinting if you turn of ClearType. I consider this a major bug.

        5
        • 9

          Did you try the ClearType tuning wizard? (it is part of Windows; for older versions it can be downloaded from MS web site)

          0
        • 10

          You might also want to google for “lcd close up” to educate yourself about pixels.

          0
        • 11

          From my investigations it does that because the RGB pixel is aligned that way on monitors to present R & G close together. The blue is almost visually non-existent as far as luminance information is concerned, so drop it from the picture. What you’re really seeing at normal viewing distances is the R & G stripes with gaps between them (which creates that vertical mesh pattern that’s visible until really high DPI). Unfortunately this means subpixel rendering (and therefore positioning) is a bit of a ‘have’, because there’s only one subpixel option available for greyscale images that works (RG). The only other useful ordering (GR) does not physically exist on the panel. For example in the “e” image above, that red pixel has a gap (blue) before the green pixel to the left. This breaks the GR stripe into a ‘wide fuzz’, and because the green subpixel to the right of the red is so close, it almost might as well be on, as with greyscale rendering. If you don’t believe me, render an image so the subpixels are shifted one to the right, ie GBR. You’ll see what’s horribly wrong with that picture. Subpixel rendering (and positioning) works much better on slightly desaturated blue lines for example, where the blue does contribute adequately to the luminance information.

          0
  4. 12

    Thanks for a great article, Tim. You really drilled into the heart of the issue, and provided clarity for understanding how we can find ‘optimum’ use of text on the web.

    0
  5. 13

    Great article i always thought font rendering was underestimated and required more attention BUT you didnt mention Linux at all which kinda disappointed me (since most of the font rendering issues i’ve seen were on Linux with Firefox).

    6
    • 14

      Hey that’s OK dude, everyone knows that Linux only has one font – Deja Vu Sans Mono, white on black, 80 characters per line :)

      It’s the most consistent!

      -5
    • 15

      So who cares about font rendering on Linux?
      That’s solely Linux developers’ issues, not something you should consider when designing a web site.
      Linux is not about content. Web design is.

      -23
      • 16

        Font rendering on Windows and Mac OS is a design issue, but font rendering on Linux is a coding issue…? Seriously… what? This doesn’t make sense to me.

        When talking about the way fonts are rendered differently across browsers and platforms, you can’t get away with taking a look at two of the three big operating systems and omitting the third.

        The article is still a great read, but incomplete without a detailed look at the Linux platform (on the desktop and on mobile devices).

        3
        • 17

          Varemenos,
          you are right, I should not have dropped Linux entirely. As font makers, we don’t typically worry about Linux too much since the rendering is robust and behaves quite similarly to Apple’s engine: there is not much difference between TT and PS, and hinting does not play a role. So, no problems to be expected on Linux, and no particular issues need to be considered from a website maker’s point of view.

          Kai,
          I think what Vlad meant to say is, “don’t worry about the font rendering on your own computer, worry about the font rendering on the users’ computer”.

          0
  6. 18

    interesting and very helpful, thank you, and thanks to Scott S for linking me to the article.

    0
  7. 19

    Nice work.Its really lengthy but well tutorial.Nice graphic as well as.Thank you very much.

    1
  8. 20

    Is there a real reason why webkit won’t switch to DirectWrite rendering?
    That’s such a deal breaker with Chrome

    3
  9. 23

    Fascinating. I’ll definitely be adding this article to my stockpile of resources to aid winning arguments working more productively with designers.

    6
  10. 24

    Good article.

    However, one thing not mentioned is that Webkit based browsers (Safari, Chrome) on OSX tend to render text differently from the main OS, Firefox etc. Basically Webkit browsers seem to do some of their own sharpening or something because text definitely looks better on those compared to Firefox for example. This can be easily seen with small font sizes where Firefox is a bit blurrier.

    Personally I’m not a huge fan of DirectWrite rendering in Windows. I find that it results in blurry fonts compared to the older methods or OSX’s font rendering. Firefox had lots of issues with this and I think it now uses some sort of hybrid method. It’s apparently a Microsoft issue underneath it all.

    1
    • 25

      Come on, a well hinted font will always look almost as sharp with DirectWrite, as with GDI
      The difference is so subtle, that it’s not an excuse to ruin large sized type with uberugly steps

      Though sharpness of GDI rendering IS appealing at first glance, smoothness of DirectWrite is far easier on the eyes for a long read
      And the strokes seem not to dazzle as much

      Just look side by side
      http://img842.imageshack.us/img842/3766/firefoxb.png
      http://img94.imageshack.us/img94/8934/chromegk.png

      2
    • 26

      Re “Webkit browsers seem to do some of their own sharpening”:
      Browsers don’t manipulate the font rendering itself. As a general rule, browsers on the same OS have perfectly identical font rendering given that they use the same graphics API. There are exceptions to this, such as the application of kerning or ligatures, or the activation of subpixel positioning are.
      What you may have experienced is that with some Mac OS setups, text is rendered darker in some browsers than in others. I have seen this myself but to be honest, have not found out yet what the exact reason is. Apple’s font rendering is simply intransparent and undocumented. Maybe it has something to do with color profiles (i.e. gamma) and their different application by the browsers.

      0
  11. 27

    What about a comparison to print? You mention that the Quartz rendering renders fonts too black, but I think ClearType renders too light. I’ve been shocked at how much blacker my fonts looked on paper after printing from Windows.

    0
    • 28

      ClearType does render lighter than it would print, but I think there’s a good reason for it: when printed, black on white contrast is not as high, as when on screen, since our monitors are light sources by themselves.
      So we have to keep color contrast on screen lower than in print.
      Quartz rendering looks really awesome and smooth, but I find it a bit more fatiguing to read long texts on a Mac.
      It’s generally an accepted opinion that font rendering on Macs is designed to reproduce print better, and font rendering on Windows is designed to make reading easier. Though Windows doesn’t succeed in its aim here as a Mac does

      1
  12. 30

    Your table of rendering modes for the various browsers is misleading in one respect: Firefox 4+ will use DirectWrite whenever it is using Direct2D (hardware graphics acceleration) for graphics – which is enabled by default if the graphics card and drivers are considered adequate to support it. So it’ll be using DirectWrite on most reasonably modern Windows systems without the user doing anything specific to activate it.

    4
    • 31

      Jonathan,
      thanks, that’s very interesting. I was not aware that Firefox automatically switches to Direct2D/DirectWrite depending on the graphics card/driver. Is there a source on the web about this?
      Are there any estimates on the percentage of Firefox users with DirectWrite enabled?

      0
  13. 32

    Very interesting article. I live on the Mac and prefer it’s font rendering algorithms (or lack of). Visually it’s my preference, but I do design for the PC environment and was unaware of all the variations and hinting issues. I guess I’ve been living under a rock. The examples are really quite fascinating. I definitely appreciate type designers even more after reading this piece. Thanks Tim!

    4
  14. 33

    this article is very similar to the contents of beyond tellerrand today ;)

    -5
  15. 34

    Another topic that should be explored is what happens to font rendering on colored surfaces, especially with regards to sub pixel hinting.

    2
    • 35

      Good question, and a surprisingly simply answer: Imagine you have some black-on-white subpixel rendered text, then add a color in Photoshop with “multiply” mode. Or, if you have black-on-yellow text then that would be exactly the same as black-on-white but with all blue subpixels turned off. Hope this gives you an idea.

      1
  16. 36

    For the CSS people out there, I institute these rules from HTML5 Boilerplate that help with rendering in Webkit and others… “antialiased” helps with the heaviness problem in Safari, while “optimizeLegibility” turns on ligatures and improved kerning for browsers that support it. Nice, gracefully degraded declarations that do not interfere with browsers that do not understand the rule (as far as I know).

    html { -webkit-font-smoothing: antialiased; }
    h1, h2, h3, h4 etc { text-rendering:optimizeLegibility; }

    4
    • 37

      One of my key clients’ stakeholders is Canonical, which as you might imagine use Ubuntu pretty much without exception (since they developed it). And within the hardcore open source Linux world the browser of choice is Chromium, the open-source platform that Chrome snapshots from (and let me tell you, browser testing against IE is a walk in the park compared to checking against a browser that rolls out new builds twice a day!!)

      Anyway, using optimizeLegibility has a bizarre bug in that browser, specifically that any text wrapped within an HREF ends up with seemingly random kerning applied. So in some cases the text extends and overlaps the surrounding content, in others it collapses in on itself, seemingly without any kind of pattern. It took me ages to identify optimizeLegibility as the culprit (even digging down through the commit logs of Chromium’s SVN to see what may have affected the text!).

      Now, I appreciate this is the most niche of niche clients, but it does highlight that there is clearly a potential problem there with optimizeLegibility on some systems. For now its restricted to a very narrow audience, but I’m mentioning it here just in case it surfaces in the “proper” build of Chrome at some point in the future and saves someone else the same hair-pulling I went through :/

      3
  17. 38

    Take a look at Tahoma on Windows and OSX. I don’t know why it’s that bold on OSX.

    0
  18. 39

    James Brocklehurst

    April 27, 2012 2:29 pm

    It might be worth remembering that a significant global user base are stuck with Windows XP, which, as far as I have experienced, uses black and white rendering by default. Many web fonts do not take this into account, and become illegible at smaller sizes.

    0
    • 40

      Windows XP uses grayscale rendering by default. Fonts can trigger b/w rendering, though. The so-called gasp table can specify that the font prefers to be rendered in b/w in certain sizes. Verdana, for example, specifies this for 9–16 px size, and Windows grayscale respects it. Since Verdana is perfectly hinted, this makes sense. Unfortunately, many web fonts out there don’t have the gasp table set correctly so they could render as b/w unintentionally in Windows XP.

      3
  19. 41

    I’ve never used TypeKit as I normally use @font-face and Font Squirrel to build a web typography kit and it’s been working almost flawlessly for the past few years or so, but I’ve always had trouble with font rendering.

    I think TypeKit serving their fonts in PostScript format is the feature that could make me switch over to TypeKit.

    Also, since when does Adobe own TypeKit?

    0
  20. 43

    @James: Win XP is set to use greyscaling by default and indeed most of the webfonts today are not hinted for such setting which is very unfortunate. Webdesigners should always test their webfonts in conditions which correspond to their userbase (and their platform/browser setup).

    You might want to look at the slides for a lecture I gave last September at WebExpo in Prague. I published them in English recently:
    http://speakerdeck.com/u/mrbrezina/p/typefaces-are-the-most-important-thing-on-the-web

    1
  21. 44

    Good & clear, straightforward summary Tim. But you really need to add Freetype rendering into your overview of webfont rendering, considering the proliferation of Android devices that are browsing the web.

    3
  22. 45

    I personally do not like the way Windows render fonts. I prefer the way OSX render fonts. I find this page very ugly on Windows, while on OSX texts are render smoothly. Although with small texts, Windows render fonts a bit sharper than OSX, but over all OSX does this job better.

    -2
  23. 46

    Chrome on Windows is the worst combination. Very jagged typeface with no way to fix. Both FF and IE display fonts much much better.

    1
    • 47

      Re “no way to fix”:
      Did you read the article carefully? Post-Script-based webfonts are exactly the way to fix the jagged rendering in Chrome on Windows.

      0
  24. 48

    Thijs van der Vossen

    May 2, 2012 10:02 pm

    It might be helpful to add that even though sub-pixel antialiasing is the default text rendering method on Macs with built-in LCD panels, using a third-party external screen can result in all text being rendered using greyscale antialiasing.

    It’s also possible for users to switch to greyscale rendering system-wide by unchecking “Use LCD font smoothing when available” in the “General” System Preferences panel.

    In Safari and Chrome you can control the antialiasing method by using the -webkit-font-smoothing CSS property which can be set to “subpixel-antialiased”, “antialiased” or even “none”.

    On top of that; all text on a non-opaque Core Animation layer will always be rendered without sub-pixel antialiasing (because of the way the GPU does compositing). You can see an example of this in the menu bar when you enable “Translucent menu bar” in the “Desktop” System Preferences panel.

    The latter is especially relevant for web pages which use CSS 3D transformations. Since these are hardware accelerated in Safari, text rendered on a HTML elements with a 3D transformation applied to it will use sub-pixel antialiasing when the background of the element is transparent. In other words, once a HTML element is moved onto a Core Animation layer, the antialiasing method of the text rendering might from sub-pixel to greyscale.

    This can result in strange visual “jumps” when the text switches between sub-pixel and greyscale antialiasing at the beginning or end of a hardware accelerated transition. See https://vimeo.com/39836831 for an example of this.

    Another interesting thing is that on iOS, the font rendering in Mobile Safari currently differs between portrait and landscape orientation, at least when the text is not rendered on a CA layer. You can see an example of this in the gif animation at http://stuff.vandervossen.net/temporary/identical-test.gif

    Even though this seems to be a bug in iOS itself (see my report at http://openradar.appspot.com/11097956), it’s still something you might want to be aware of.

    1
    • 49

      Thijs,
      thanks for providing these notes. Of course, the article contains numerous simplifications and generalisations, and there are many more details one could add. I tried to help the reader understand the basic principles and focused on the issues that the website maker’s decisions depend on.

      0
  25. 50

    Henk van den Bor

    May 5, 2012 11:39 am

    Thank you, the article is by far the most informative on this aspect of factors to consider when choosing and working with css fonts I have come across lately. I will now be able to explain the differences in rendering much better to my customers.

    0
  26. 51

    It would be interesting to see ubuntu’s font rendering added to this article, its got its own unique font rendering style different from windows and osx that IMO looks great.

    3
  27. 52

    Why do the fonts in Firefox look more “scrappy” than in IE – we recommend our schools to use Firefox but we still get complaints about the look of it. Vanessa

    0
  28. 53

    El Warbo Grande

    April 30, 2014 7:51 pm

    There’s just one thing I can’t understand still and that no one ever seems to talk about. Why is it so hard for Windows to render web fonts the way Macs do? Why do they have to resort to ‘technologies’ like clear type, when someone out there (Apple) already has a superior solution? Why is it so difficult for Windows to render fonts on browsers when it has no problem rendering on-screen for applications? This whole thing baffles me and has for years now. Why can’t Windows just get it right?

    2

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top