Font Rendering Explained

One aspect of web design that still limits everyday, is the horrendously poor choice of fonts we have at our finger tips. With only a handful of truly system universal fonts at our disposal, its not a surprise that font delivery systems such as Font Squirrel or TypeKit have appeared to fill in the holes.

But there is another aspects of fonts which is discussed a lot less frequently than how to get curvaceous handwritten fonts from the designers PSD to the ends users screen; that is font rendering.

What is Font Rendering

When it comes to trying to put characters, or any digital asset, on the screen it needs to be broken down into individual pixels. So the blue sweeping letter ‘e’ shown here, needs to be mathematically converted into the rather sharp looking blocks. This analogue to digital conversation that takes place is called font rendering.

However unlike many problems on the web that stem from poorly adopted standards, this problem derives from the very heart of the operating systems. So Window’s machines will use different render techniques from Linux machines, and then Macs again. On top of that, the browsers themselves are adding their own rendering technologies to complicate matters. Some of these technologies I’d never heard about, like DirectWrite, Windows latest API for glyph rendering.

Add to the mix a plethora of standardised formats of TrueType, WOTT, PostScript, Cufon and EOT. The font waters suddenly become very murky.

If you’ve used any of the font delivery systems, my personal choice is Font Squirrel at the moment, then you’ll undoubtedly have come across the artefacts and sharp edges that some browsers render the characters with. Not that this problem is localised to just custom bundled fonts, those “web safe” fonts also suffer to a degree.

To add some clarity back into those waters, I highly recommend this article I stumbled upon by Berlin consultant Tim Ahrens on the subject.