Type rendering: web browsers
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!
23 Responses
Comments are closed.
Tim-Great post. I had no idea the rendering engines were specific to both the OS and browser in combination. You guys are real pros. Keep up the great work.
Great post Tim. It’s great to see the collective knowledge of the webfont community put together in one place like this for easy reference.
Although I know you’re trying not to delve into minutiae here, it’s not quite true that every browser on Mac OS X renders text exactly the same. Firefox generally displays fonts a bit heavier than Safari, for instance.
Tell me more about what you’re noticing, Matt. I know of a few CSS-related factors that can subtly change how type is rendered in different Mac browsers (which I plan to explain in a future post), but as far as I know the browsers themselves are not responsible for rendering differences.
Here’s an example from Andy Clarke. I generally haven’t noticed examples quite so extreme though.
I think that this might have been improved in FF 3.6, but I’m not really sure. The differences are generally small enough that it doesn’t much matter to me, but they’re there. Also, I think that the differences are more pronounced in light text on dark backgrounds.
@ Matt Wiebe – Firefox used to be noticeably heavier, but comparing side-by-side now it’s identical to Safari/Chrome (notwithstanding -webkit-font-smoothing:antialiased can shift more than two weights down). Keep in mind Safari isn’t using WOFF from Typekit, but Firefox/Chrome are. I’ve noticed this affecting kerning pairs, but the weights are very even.
It’s also worth pointing out that Safari for Windows allows you to adjust the anti-aliasing by using either Cleartype or various other settings like “strong” or “medium” which are closer to Mac rendering.
That’s a good point Joshua. I’ll mention Safari’s rendering preferences in a future post. I decided to save it, because what’s really interesting there isn’t so much that we need to test for this … but the philosophical argument to be made about which rendering strategy is best (Apple’s or Microsoft’s).
Fantastic post and I actually learned something new hear.
But what about Linux? Normally it wouldn’t matter but is it similar to Android devices?
I haven’t done enough research yet on type rendering in mobile devices, but they certainly deserve a dedicated post (or two). If anyone can share resources, please comment!
Type AA in Ubuntu is usually very good, it’s as smooth as OSX. Depending on the font it puts more or less weight, than can matter a lot.
Very helpful round up. I’m definitely looking forward to reading the next post about the font files themselves. The current webfont situation is a bit chaotic but it’s encouraging to see some order emerging.
Great lesson about type rendering. This post series helped me to understand how all this stuff works, thank you !
More great work, Tim.
Mobile devices definitely make things muddier. Android devices and Linux systems should be largely similar, since they both use Freetype, but they may not be identical, since there are options in using the Freetype engine that can be set differently.
IPad
Safari.
Webtoolkit render not working. Ironic for such a slick device. Spec a font/ file. Not wysiwyg
So — when is Typekit going to provide us with a way to switch off webfonts when a) fonts aren’t hinted and b) one of the Windows rendering engines is used?
As it is now, fonts like Calluna are pretty much unusable on Windows platforms: people complain that they are ugly and unreadable. I would really like to be able to fall back to standard fonts on any platform which will render these unhinted fonts as crap.
Well, it is not true that fonts on all browsers on Mac OSX look the same. For example Firefox supports more OpenType features than Safari which can heavily influence how things look.
“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.”
DirectWrite looks absolutely horrible. It is completely unreadable even on my very high-quality 30″ Cinema Display.
Why?
Because it makes the same mistakes that Apple’s technique does — it does not attempt to fit the text shapes into the LCD pixel grid, leaving them very blurry.
That’s not really debatable. If the font’s shape doesn’t fit into the pixel grid, it’s by default blurry.
I was using the Firefox 4 beta where DirectWrite is enabled, and had to turn it off straight away as I could not read more than 500 words without triggering a migraine.
As soon as you add text-shadow things change a bit. Try adding a text-shadow (text-shadow: 1px 1px 0 #ffffff) to some Century Gothic with a font-size of 21px or less. Also play with font-weight, there’s a few differences there between IE, Chrome and FF.
Maybe interesting for you, we have statistics about how much users have cleartype enabled:
http://www.webmasterpro.de/portal/news/2010/08/19/schriftglaettung-und-cleartype-sind-standard-webanalyse-statistik.html
In our tests (with a competing web fonts service which suplied Trade Gothic) we’ve had strikingly different results in Firefox Mac as compared to Safari. As far as I was aware, FF Mac does *not* use Core Text yet; it’s mentioned here as a Gecko 1.9.3 feature: http://hacks.mozilla.org/2010/02/mozilla-developer-preview-gecko-1-9-3a1-available-for-download/
Gecko 1.9.3 should be first seen in Firefox 4: http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29#Usage
Perhaps I’ve got that wrong and CoreText is employed in FF 3.6. But even so, all is clearly not equal: our fonts came out much heavier set compared to Safari.
Part of our testing involved comparisons with Cufón, which came out practically identical to Safari’s rendering of the @font-face declared font. So we’re definitely assuming that Firefox has some work to do.
It’s absolutely essential to test type rendering in Firefox for Windows if you’re using
font-size-adjustin your stylesheets: it can cause trouble even with well-hinted fonts, most noticeably when your text is set in all-caps.OSX also tends to faux bold fonts — fonts on osx look consistently heavier than windows fonts. This has caused a few issues in the past where I couldn’t use the appropriate sized font because in OSX there was a 1px gap created that didn’t exist in Windows.