A look at Font replacement

Thanks to font replacement, we as web designers can breathe a sigh of relief (feel free to pause for a sigh). No longer do we need to restrain our imagination to just a handful of web fonts as we now have a plethora of available typefaces at our disposal.

So, what was the problem?

Way back in the 90′s the web had a pretty tough time, visually. The available fonts were limited to whatever fonts developers knew the browser/machine had installed, so in practice, that meant the default set for Windows/Mac: Verdana, Times and Arial etc. More recently, developers looked to create a way to introduce a variety of fonts to the web. The term “font replacement” is basically just the ability to use custom fonts on the web without having to resort to the standard browser fonts available. As the web grew, developers came up with several inventive ways of embedding fonts into web pages and here we will list some of the ones that have particularly interested us over the years…

sIFR

sIFR which stands for “Scalable Inman Flash Replacement” is one of the original methods of font replacing and uses both flash and JavaScript to implement font embedding. It basically replaces selected text with a Flash object that contains the desired font. One of the advantages of sIFR is that the text can be accessed by screen readers and can still be selected by the user.

Positives:
•    It was really the first method available (and was very clever at the time)
•    Can be accessed by screen readers and text can be selected

Negatives:
•    Relies heavily on Flash (so doesn’t work on iPhones and iPads)
•    There is a performance issue
•    The embedding tends to get blocked by flash blockers
•    Can be very difficult to style (which in the end sort of defeats the purpose)

Cufon

Cufon takes text and converts  it into vector graphics, using the bespoke fonts held on the server. Cufon consists of two parts: The font generator, which converts the font and a rendering engine that’s written in JavaScript.

The Generator:

The Generator Cufon uses to convert your .TTF (TrueType) and .OTF (OpenType) files is basically a window over the top of Font-Forge. The generator takes the text and converts it to SVG (Scalable Vector Graphics) and then parses the SVG paths to VML (Vector Mark-up Language) paths. This particular step is crucial in IE as Internet explorer (sucks) supports VML natively.

The Renderer

The renderer consists of 3 parts – a “Core”, which provides the API and basic functionality, and two rendering engines. One of the rendering engines is VML for IE, while the other uses the widely supported HTML5 canvas element.

Positives:
•    Has multi-browser support
•    You’re able to style the fonts well (shadow, gradient, etc)
•    It compresses extremely well, usually weighs in 60-80% less than the original.

Negatives:
•    Text isn’t selectable or screen-reader compatible
•    Best used in headers, titles and subtitles, not great for large bodies of text
•    JavaScript is required and therefore if users have this turned off, it won’t work

@font-face

Possibly the most talked about and widely used font replacement method. @font-face is a method of using a wide variety of fonts without having to rely on flash, PHP or even JavaScript. @font-face uses CSS to implement custom fonts on a web page. Fonts are held on the server and linked to from the CSS file – users will download the font as part of the page load. The @font-face method is used by the well-known, newly acquired Adobe Company “Typekit” as well as companies like “Fontdeck”, “Font Squirrel’ and several others. However Typekit does use its own JavaScript library to identify the user’s browser and in turn fires events to provide better control over fallbacks.

How it works

@font-face makes use of the CSS @font-face property and allows you to directly link to your @font-face font file and assign a font-family name to the file for use in your CSS document. One of the benefits of font-face is that you can have the font stored externally and the users do not need to have the actual font stored on their computers (however the font will be stored in browser cache). There are two main different font file types used in @font-face, .eot and .ttf. Internet explorer won’t understand .ttf and therefore we must link to the .eot file first.

Positives:
•    Accessibility is maintained – meaning it degrades well.
•    Unicode support
•    Font Styling (CSS) support
•    No initial need for JavaScript, PHP or flash to implement @font-face

Negatives:
•    Some fonts can be heavy to download.
•    No common font-file format on all browsers.
•    Licensing these fonts can be pricey and therefore distribution can be an issue.

Google fonts API

Google have released their own font archive that is open-source and available to all. Their archive is steadily growing with over 200 free available fonts. It uses @font-face to embed the fonts on your web page. One of the best things about Google fonts is that quite a lot of your user’s may already have that particular font saved in cache meaning your pages will load faster. Also the fonts are held on Google’s server which again helps to speed things up.

Positives:
•    Open Source licensing means these are free to use and distribute
•    Your font might already be in the browser cache meaning the page will load faster

Negatives:
•    Uses JavaScript to embed the font
•    Other than that, it’s pretty nifty

Legalities and distribution

Unfortunately like anything these days, there are legal implications. Many fonts used on the web are under licence and in order to use the fonts we have to pay fees. There are a few common licenses fonts tend to have such as “one-site basis”, “multi-site basis”, “desktop license” and “web license”. It’s always important to check what license the font has before using any.