The 2 commonly used terms of “typeface” and “font” seem to be used interchangably these days and though this might not be too important for practical work, especially when designing for the web - it is an intersting aspect to consider and understand. The history of this terminology is interesting, worthwhile exploring further and will hopefully highlight the labour and love that goes not only into the design of a typeface but also the collation of variants into a font file. I will not go into details here but give you a quick definition of the two terms.

In the early days of the web - the choice of fonts was fairly limited and this state of affairs remained in place until recently. Webdesigners could not approach the typography for their designs the same as a print designer could. The choice of fonts available locally on the work machine was all a print designer needed to worry about.

For print design - it is all a matter of purchasing the appropriate license for your desired font or font family, install it on the computer and start working with it immediately.
The installed font file will make any type variant available instantly to use within the design. Easy :)

It is a whole different game for webdesign, however. Before the evolution of webfonts - the choice of available fonts to use was limited entirely to the commonly installed system fonts, varying on different operating systems. Some print designers moving onto webdesign would struggle with the limitation and find the unpredictable rendering of their carefully crafted, pixel-perfect layouts often frustrating and inhibiting.

Though this might have been a hurdle for some - others would argue that this limit of typefaces to choose from for any given website design was liberating, inspiring and pushing skills to the limit. With only a set number of fonts reliably available on end user machines - the designer was required to work within those contraints and push their creativity to still produce a strong and high quality end product.

Font stacks became the focus of designers aiming to ensure good typographical display of copy and the task of typesetting had to come with certain downfalls. The choice of an appropriate font stack was vital to produce clearly presented type on the web, considering the spacing and overall layout for all types was essential.

font replacement techniques

With these limitations of available fonts to choose from - designers were desparately looking for solutions to use mosre custom fonts. The developers and programmers were listening and over a period of time quite a few different solutions surfaced. The aim was to replace short sections of text, such as headings and short citations, with either an image or a custom font directly. The drawback of most of these solutions remains their reliance on enabled Javascript and/or Flash.

Most of the technqiues emerging in the early 2000s work in a similar way: first, the standard (X)HTML page is loaded into the browser. Next, a script is run (Javascript) which checks for browser capability and the selected text section’s type is replaced with a custom setup. This could be replacing the text with a static image, containing the text in its chosen typeface, or replacing the standard font with a server-hosted, embedded file.

Though on a fast connection and with a speedy processor - this change is made almost instantly it is not unusual to see the FOUC (flash of unstyled content). If the connection or computer speed it slow then these techniques do give away the game. For a brief instance, the webpage will be rendered using the standard fonts before the replacement is complete, visibly replacing the existing typeface with the final one. Unfortunately there is not much you can do to stop this from happening apart from making sure to use the lightest and most minimal scripts to reduce loading time which by no means guarantees a fast replacement on page load.

Due to the disadvantages mentioned above I don’t want to go into much depth with these techniques. But it will be useful to know a little bit about the most popular ones so here is a quick look at the most common ones:

simple text replacement with image

The most commonly used trick in the past used to be to simply replace the text with an image containing the same text, presented in its preferred typeface. The typical method is to keep the text in the HTML page and use CSS to display an image as background image via CSS. Typically, the text then gets hidden with a negative text indent, allowing it to be accessible still to search engines and screen readers.
The advantage of this technique is that it relies only on CSS and no additional scripts.

sIFR (Scalable Inman Flash Replacement)

Based on IFR (originally by Shaun Inman) - this technique was developed in 2005 by Mike Davidson, further developed and improved over the following years with the help of others. sIFR allows you to replace text elements with a Flash file via Javascript. The font is embedded into a .fla file and stored on the server.
With this setup, the (X)HTML page get loaded first. Then a javascript function checks whether the browser has the Flash player plugin installed and if found proceeds to look for your set tags, ids or classes. Next, the found elements get measured (again, via a Javascript function). A Flash movie gets produced at the same size as the element/s measured, the HTML text gets used in the Flash file and the resulting Flash movie is placed on top of the relevant HTML element. Actionscript then fine-tunes text size.
If Javascript is not enabled or the Flash player plugin is missing, or both, the browser will simply show the original text.

Cufón

Cufón takes a similar approach and replaces text with a vector graphic via Javascript. This technique relies on your font being converted to a compatible format via their own generator and the resulting file to be hosted on the server.
With Cufón, there are two steps: first, you use the Javascript engine to convert your font into the right format, ie the representative vector equivalent. Secondly, you target your chosen elements by editing the Javascript. This technique is relatively easy to implement and relies on one additional script.
If Javascript is not enabled the browser will simply show the original text.

P+C DTR(PHP + CSS Dynamic Text Replacement)

Based on Dynamic Text Replacement by Stewart Rosenberger - this technique is similar to its original but avoids the use of Javascript. Initally developed by R. Marie Cox - further developed by João Makray, P+C DTR uses output buffering function of PHP to find the heading tags on the page, extract the text and assign inline styles, pointing to the image generation script. This method takes the load of the replacement onto the server, therefore cutting out the reliance on client-side scripts.

There are good arguments for simply specifying the font family, rather than listing specific fonts, as this will allow the user settings to take over and give the end user a familiar display, in keeping with their set preferences. However, this will not allow for much precision for spacing and overall layout. This is why font stacks are the best method to control text styling.

Choosing the right font stack is the only way to ensure consistent and legible presentation of text elements within any webpage, be that headings, paragraph text, annotations or footnotes. Font stacks go beyond choosing only a specific font family and add more control over the typographical display.

font families

There are 5 different font families used for text styling via CSS; the examples shown here are styled by applying the generic font family alone.

1. serif for example: Georgia, Times, Times New Roman
2. sans-serif for example: Lucida Grande, Helvetica, Arial, Verdana
3. monospace for example: Courier New, Lucida Console, Andale Mono
4. cursive for example: Caflisch Script, Snell Roundhand, Zapf-Chancery
5. fantasy for example: Impact, Copperplate Gothic, Papyrus

Though all can be used - I would say that you will mainly use the serif, sans-serif and possibly monospace for your designs. The others are not as common and you are not likely to find many designs which will require these two elaborate typefaces; though they might have a place for styling single words or lines of text occasionally.

definition: font stack

A font stack consists of a list of fonts, defined in the font-family declaration in CSS. Listed in order of preference, the fonts are used when available via the end user’s computer.

commonly used font stacks

Go online and do some research on recommended font stacks and you will find a huge list of various combinations. Opinions vary as much as the font choices. Here are a few of the most popular stacks, some widely used - some as set by default via coding apps, again, the examples shown here are styled by applying the generic font family alone (note the evident differences in typeface appearance):

• Arial, Helvetica, sans-serif
• Courier New, Courier, monospace
• Times New Roman, Times, serif
• Georgia, Times New Roman, Times, serif
• Verdana, Arial, Helvetica, sans-serif
• Geneva, Arial, Helvetica, sans-serif

These font stacks are typical for their reliance on core system fonts alone and there is no reason why you cannot produce an impressive design with these fonts alone. However, looking further into the newer system fonts now found on newer operating systems will allow you more choice and finer selection.

When designing a page for the web - you will not only need to find the one typeface which you would like to use but expand your search into possible alternatives which can be substituted for your first choice. Luckily there are various resources out there for you to check on availability of fonts installed on different system and even via specific apps. One of the best I have found is the font matrix by Richard Rutter.

If you have not yet given typography for the web enough time or attention - start by creating your own font stack. Your font selections need to be carefully considered and work well across all operating systems and devices.

You could start with the Font Stack Builder by Phil Shaw which gives you clear information about the availability of fonts on different systems and gives you a precise tool to create your own font stack from scratch.

Before you begin - consider the context of your site and make your choices accordingly.
? Does a formal and more traditional typeface suit?
Which typefaces will best suit a site aimed at young people?
Will your selected font/s be clearly legible at all sizes when considering your target audience?

Once you are clear about your objectives - view and study all possible and suitable typefaces carefully. Chose you preferred typeface and select appropriate substitions and the relevant font family. The list of your chosen fonts, comma separated, should be as follows:

1. your preferred font
   If the name of the font family is more than one word, you will need to add quotation marks around the full name.
2. a close alternative
   This could be simply your first alternative, or a font selection based on the availability of the preferred font on different systems
3. one or more possible substitutions
   You can add several alternatives, as many as you think you might need, though you don’t need to many in most cases.
4. font family
   Lastly, always include the correct font family. This will ensure a safe fallback should all other fonts be missing.

Take care to select fonts which are ‘comfortable’ with each other, which are similar in x-height, character width as well as weight and you will ensure your nicely crafted layout will not be compromised if your preferred font is not found. This is not quite as easy as it might sound. Typefaces of the same generic font family do vary, sometimes quite substantially, in proportion and weight.

Imagine a fixed layout and your plans for headings, for example. You might aim for a certain width, at an estimated number of characters per line. If your font stack is well thought through - your design and layout should hold throughout changes of actual font used. In case you did not plan ahead and chose fonts varying too much - you might see some misbalanced elements within your layout.

Take a look at the example below, showing text in a graphics application (Illustrator). Though this is not a true representation of how a browser would render the font - it does show the difference between these sans-serif typefaces quite clearly.

Though you should always use a good font stack to control the typography of your web designs - you can also use webfonts which are font files embedded in your website using the @font-face rule. The font stack will include your chosen webfont in its first instance, the rest of the fonts listed will then act as a fallback in case your chosen embedded fonts should fail.

The technique of webfonts via the @font-face rule has been around for a number of years already, initially used in Netscape Navigator but then discontinued. Microsoft developed its own font format for use with the @font-face called ‘Embedded OpenType’ format (.eot) which has been in use since IE4. Though this was a great move towards more choices for webdesign - it remained a somewhat closed area due to IE’s reliance on its own font format.

Soon other browsers followed suit and started to support the @font-face rule - however, the font formats supported were not the .eot but the more commonly used formats, such as TrueType (.ttf) and OpenType (.otf) and others. Now, Safari, Firefox, Opera and Chrome all support the @font-face rule.

web font formats

EOT : Embedded OpenType : .eot

This early font format by Microsoft is proprietary and exclusively supported by Internet Explorer. EOT fonts are required for all versions of IE, especially for all earlier versions. Only IE9 includes support for the WOFF format as well.

TTF : TrueType : .ttf

Developed by Apple as a competitor to Adobe’s Type 1 format, used in PostScript. TTF fonts were soon widely adopted as the most common format for system fonts and are now compatible with most operating systems.

OTF : OpenType : .otf

The OTF format was developed by Microsoft and Adobe and is based on the TrueType format. It does include typographical features such as ligatures though these are not yet fully supported by all browsers.

WOFF : Web Open Font Format : .woff

The WOFF format is currently in the process of being standardized and the W3C who published a working draft in July 2010 is expecting it to become the interoperable format which all browsers will use in future. It is important to note that WOFF is not actually a font format per se - but rather a wrapper containing fonts such as TTF and OTF.

SVG : Scalable Vector Graphics : .svg

SVG fonts are different to other font formats as they contain the letter outlines as vector objects. SVG fonts are usually quite heavy in file size as they do not have the compression built in as other formats do. The most common use of this format remains either the iPhone and iPad, prior to iOS4.2, or their implementation via web font providers (as covered in more detail later).

Before you go ahead and use any of your favourite fonts - you will need to make sure to check the End User Licensing Agreement (EULA). If your license is specifically for embedding or includes the permission to do so - you are safe to use the font via @font-face. If you are not sure what your license permits - it will be best to check with the font vendor and ask before using the typeface for your design.

In order to use the @font-face rule - you will need to ensure that the font file, in its appropriate format, is hosted in the site’s directory on the server (local or remote) . It will then be loaded via CSS, enabling the browser to render the copy in your chosen typeface. The @font-face rule works by allowing you to link to a font file in your style sheet. It is the same principle as linking to images, for example.

STEP 1 - convert font file to appropriate formats:

There are various online tools available to use for font conversions. Some allow you to convert to specific formats only, others are available as downloadable app. For example, the ‘eotfast’ app is a PC only program which converts .ttf fonts to .eot.

By far the best tool I have come across and which I would highly recommend is the @font-face generator by FontSquirrel. The site is one of the best resources for both free and commercial fonts. Licenses on offer cover the embedding specifically and as part of the resources - you can use the generator to convert your font files to different formats.

The @font-face generator is fantastic and gives you different tool options, after processing your font - you will be able to download a folder of resources:

The presentation of these resources is nicely compiled into a demo HTML page, allowing you to view the font at different sizes, in a sample layout and preview the rendering on windows. There is also a section on glyphs and languages as well as instructions on how to use the fonts.

STEP 2 - write the CSS:

The CSS code in its most basic form:

Starting with @font-face, first the font-family is defined. The src property contains the link to the font file itself, followed by the font format. The linked font is then applied to the chosen HTML element. This would be all that’s needed if all browsers had the same functionality in regards to font formats.

As browsers however vary - the @font-face rule will need to double up and declare different sources and URLs, linking to the different font formats. For InternetExplorer - the selected font file will need to be in .eot format, for most other browsers the format could be .otf, .ttf or .woff - and iOS prior to 4.2 will require .svg.

The problem is that IE will try to implement the second alternative as well and try to download it. By including format() - which IE does not understand - it will reverse back to the previous declaration and implement .eot. Developers point out that it will be better to avoid the error which IE encounters when looking up the file name via the url value.

One solution around this is to include a local reference in the src property, before the url. IE can not understand the local() location nor multiple locations so it will simply implement the last valid declaration, in this case the .eot file. This technique has the added advantage of loading time - both for you while producing the site and for your site visitors should they have your chosen and embedded font installed on their computers. Listing multiple locations you can also list multiple formats within the same src property.
Bear in mind that Safari will require the PostScript name of the font - you should include it as well if it differs from the full font name.

One solid and widely used solution for this is the "Bulletproof @font-face syntax" by Paul Irish.

You will also need to include the different variants of your typeface, if required. So if you want to use regular, bold as well as italic - make sure to include the correct details as well. As you can see - the use of many variants or many fonts - can add to the length of your CSS considerably, as well as requiring more calls to the server and also increasing the loading time (especially on mobile devices). So plan ahead carefully and choose your select typefaces carefully before collecting your webfonts for conversion and inclusion.

As this approach gives control over to the site visitor’s machine and accesses the local version of the font - there were some concerns about the guaranteed use of the chosen font. If, for example, the font name on the local machine was altered or if it is referenced differently - the wrong font might be used. To address this - Paul edited a second version, the ‘smiley variation’ which he recommends over the first version.

Instead of specifying the local font name - a smiley face character gets inserted in place of the name. While this does prevent the local font from being used - the local() location still prevent IE from trying to read the other font formats and keep it using its allocated format .eot.

Another solution to prevent the error for IE was developed by Ethan Dunham: The New Bulletproof @Font-Face Syntax. It works by appending a question mark to the .eot declaration. This will be interpreted by IE as a query string, causing it to ignore the rest and implement the .eot font.

While I was learning how to use the @font-face rule - "Bulletproof @font-face syntax" by Paul Irish - was and still is the main article which I refer to and which has informed my understanding and current coding practices. Make sure to read it yourself, it’s brilliant and clearly outlines how this solution was developed. Thanks, Paul :)