Choose your web fonts wisely
I’ve lost track of how many times I’ve used the phrase, ‘right now is an exciting time for type on the web,‘ but amidst all this excitement, let’s not forget that there are some very important considerations we need to bear in mind when selecting all these lovely new typefaces for our projects.
I’ve just been reminded of a very important lesson that I occasionally forget: test web fonts on Windows, because a lot of them look shit.
It’s something we can all easily forget when we get wrapped up in having multiple typeface choices available to us, but it’s a huge consideration.
The slightly more daunting prospect is that it’s not simply a case of good or bad; there are several variables at play when you break the consideration down into its component parts. Here are some of the main ones, listed loosely in order of the production line (i.e.: from original typeface design through to the end user’s experience of the font):
- How suitable is the design of the typeface?
- How well is the font hinted?
- From which font delivery service is it being served?
- What font size is being used?
- On what system configuration is it being viewed?
How suitable is the design of the typeface?
This is a somewhat arbitrary concept and one you could quite literally write a book about, but I’ll mention it here briefly because it’s a personal decision that does also have knock-on technical considerations. As a very rough generalisation, the more intricate the details in a typeface, the less suitable it will be for body type. You could therefore have the most excellently hinted font in the world, but used in the wrong context, it could still look terrible. So, in the first instance, the web designer has the responsibility of choosing the appropriate typeface for the job before further technical considerations come into play.
I think that’s all we need to say about that.
How well is the font hinted?
Font hinting is a bit of a dark art, and something many of us choose to gloss over. Don’t, though, because even a loose understanding will help explain the way type is displayed on screen, particularly on Windows.
Essentially, ‘hinting’ is the act of inserting TrueType instructions into a font file, which are needed for Windows rendering engines to appropriately fit the font to the pixel grid. If you’ll forgive my shameless plug, Tim Brown wrote an excellent article about Type Rendering and Web Fonts for our latest issue of 8 Faces, in which he said:
TrueType instructions are an expensive, time-consuming effort that requires specific knowledge, patience, and technical and aesthetic aptitudes. Web fonts that have TrueType instructions tend to look very good on Windows; those without often do not.
As Tim mentions in the article, individually hinting every web font that becomes available is something of a pipe dream, but there is hope: Microsoft’s new rendering engine DirectWrite (a successor to ClearType) brings _OS X-_like type rendering to Windows and is used in IE9 and available as a preference in Firefox 4+.
An alternative to using TrueType instructions is to use PostScript instructions instead, which often work better on display typefaces for those users who have yet to update to a DirectWrite-capable browser.
For a more thorough look at type rendering, be sure to read through the excellent articles posted on the Typekit blog. I’d also encourage you to read this slightly older article by my studio mate Jon Tan. I know Jon has been doing a lot of detailed research into the current type rendering landscape recently, and I’m hoping that my mention of it here will bully him into writing a new post!
From which font delivery service is it being served?
When a typeface and its fonts are listed on multiple font delivery services ( Typekit, Fontdeck, Google Web Fonts, webfonts.fonts.com, WebINK, et al), you could be forgiven for assuming that the fonts served will be identical and, when viewed on a Mac, that might seem the case. However, viewed on a PC browser without the DirectWrite rendering engine and without the enhancements mentioned above, the differences become startlingly apparent. In fact, even if the enhancements mentioned above are in use, the difference can be obvious: what if one font delivery network serves a font file that employs PostScript instructions and another does not?
Consider LFT Etica, by Type Together, which, for a while, we were testing as the body face for the Smashing Magazine redesign. On a Mac, versions served by Typekit and Fontdeck look virtually identical (for the purpose of this demonstration, let’s limit ourselves to just two services), but examine them on a PC and you’ll see some noticeable differences.
Look at the lowercase ‘w’. Served via Fontdeck, the apex of its middle strokes falls shorter than the x-height and could be considered a little strange, especially since it’s not true to the original design. Overall, though, the type feels a little more crisp than the Typekit version.
So which version do we choose? Both have their pros and cons; ultimately, it comes down to the designer’s preference for what is most appropriate overall for the task at hand.
What font size is being used?
At larger sizes, the opposite of our body example is true: Typekit’s version of LFT Etica Extra Bold does a better job of anti-aliasing the outlines when compared to Fontdeck’s version. It looks like they’re using PostScript outlines here to achieve this, especially as zooming in on the screenshot reveals greyscale (bi-directional) anti-aliasing.
So again we must ask ourselves: which version do we choose? And again we must conclude that it comes down to the designer’s preference for what is most appropriate overall for the task at hand. There is no ‘right’ answer.
On what system configuration is it being viewed?
We’ve been talking about it throughout the entirety of this post, but technically the actual system configuration of the individual user is the last stage in the process of the ‘type experience’: the designer’s choice of typeface, the quality of the original font file, the version being served via a delivery network, and the size(s) at which the font is rendered are all, ultimately, at the mercy of the user’s personal set-up.
Every single one of the stages prior to this forms part of a fail-safe plan to get type looking as good as it possibly can, but sadly we just can’t predict…
- the operating system;
- the browser;
- the browser’s rendering engine (which can be limited by the underlying operating system);
- the screen size, type, and resolution;
- the power of the computer;
- the environment in which it’s being used (think desktop in an office versus mobile phone in direct sunlight);
- and numerous, personal, user-controlled system preferences and browser preferences.
In the face of such adversity, the temptation is to give up and / or ignore all of these considerations. But don’t, because font files get tweaked, companies optimise their services, browsers improve their rendering, and technology — and users — get smarter.
And that is why it’s so exciting to be working with type on the web.
(I hope the above was helpful. In the next post in this series, I’ll be looking at how I’ve been taking a ‘type outwards’ approach to the Smashing Magazine redesign.)