Today, the commercial and free fonts available to graphic designers number in the hundreds of thousands. While this rapid development has given us almost unlimited combinations for font pairings, the ability to implement most of these fonts into our designs has been limited to print mediums.
In website design, the typography we use is limited by the fonts installed on the devices accessing our designs.
While there are a number of options available for including custom fonts in your designs, understanding which fonts can be used and how they will be implemented is crucial in making sure your client’s design turns out as you had planned.
As web developers, it’s important that we do everything in our power to accurately reproduce the original designs that our clients have approved.
Now, you’re going to occasionally run into things that require modifications to the original designs, that’s unavoidable. However, when it comes to the fonts that you’re using in your mockups, there should be almost no reason we’re showing clients designs that have different typography than what the end product will have.
The key to making sure we’re designing mockups to look like the final website will look like is to have a good understanding of what fonts we can use, what types of styles we can apply to them and what technologies we can use to embed them on a website.
Legalities
The first and possibly most important thing to understand is that not all fonts are even legal to embed on a website. This is especially true with commercial fonts.
While you should always check the license of the fonts you’re using to be sure, three fairly large font providers that prohibit the free use of their fonts on the web are Adobe, Monotype and Linotype.
Most of the fonts available from those providers have paid, web font versions, but the license is usually only good for a single website.
Using them is going to drive up the cost of the design and may be difficult to justify to a customer when you could easily find a similar font that is free to use on the web.
Style:
Another important thing to remember when creating your mockup is that not all of the styling options you can use in design programs like Photoshop or Illustrator are things that can be translated onto the web.
Most of the styles like drop shadows, stroke, and pattern overlay, as well as anti-aliasing methods such as “crisp” and “strong” don’t have any way to be implemented using non-Flash web development techniques.
When styling your fonts in a design program, be sure to steer clear of styling methods that can’t be used on a website unless the text is going to be a part of an image rather than implemented as actual text on the site.
Methods for Implementing Web Fonts
The three most common methods we use to implement fonts on a website include a degrading font stack, a JavaScript program called “Cufon”, and a newer, more flexible font-replacement technology called “@font-face”.
Degrading Font Stack:
A degrading font stack is nothing more than declaring a series of fonts starting with the one you want to use in your design, and then listing out other, more common fonts to act as a fallback in the instance that the user’s device doesn’t have your font of choice.
For example, a common font-stack used for Helvetica looks a little like this:
font-family: "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
As you can see, the most desired font starts at the front of the font stack. Since Helvetica Neue Light is not installed on that many devices, the font stack slowly starts to degrade to “the next best thing”, ending ultimately with the least desirable, yet highly prominent web-safe font families.
Cufon Font Replacement:
Cufon is an interesting little program that takes a font and maps it out into a script. It then takes that script and replaces text on your website each time a page is loaded.
It sets the height of the actual text to zero, making it invisible to users. Then, taking into consideration your font styles, it replaces each word with an image that looks exactly like the font.
Now, I’m particularly a fan of this method because it’s easy to use and looks really, really good. Because the text is rendering as an image, it displays much smoother and more vibrant than many devices display text.
There are some downsides, though. First off, it does contribute to page load times, which are critical to the user experience. It also can really only handle small batches of text. I prefer using them for navigation menus or headers, since there’s usually a minimal amount of text being replaced in those areas.
Another thing that can be a problem with Cufon is really just a problem with the fonts themselves. Cufon can’t manufacture a glyph for a font family. If the font file doesn’t have the glyph, it can’t display it.
While most fonts are going to have a majority of the glyphs you might need, I’ve seen some that don’t even have basic glyphs such as hyphens or other forms of punctuation.
In the end, I would definitely recommend using Cufon for font replacement if we’re going to be using it for Navigation Menus or Page Titles on the site.
@font-face:
When it comes to implementing a site-wide font that’s going to be used in a majority of the content area, I would recommend @font-face. This technology is a reliable method for mass font replacement, but it’s also limited to use in more modern browsers.
@font-face has a minimal impact on page load times if you’re not using too many different fonts, and it’s also able to emulate almost all of the CSS styles that you would use on regular text.
When we implement @font-face typography, we also use them as a part of a degrading font stack so you get the benefits of displaying the exact font you want on modern browsers, and slowly degrading to other fonts depending on what’s installed on the device with older browsers viewing the site.
As far as the downsides of @font-face are concerned, it can really be difficult to judge the quality of the font-replacement until you’ve actually tested it on a site. Different browsers render these fonts differently, and some fonts look great at certain sizes but very rough at others.
You can’t really use your design program to determine what these special fonts are going to look like at different sizes, so the only way to be sure if a font is going to look good is to test it out on a webpage.
There are several free tools out there to help you do this, but we also offer this for free. If you’ve found a free, indie font you really like but aren’t sure what it’s going to look like rendered on the web, we can set up some tests for you to give you an idea of what it’s going to render like.
Conclusion:
With careful planning, you can implement truly amazing typography in your clients’ designs. Just be sure to always check your fonts’ licenses, avoid showing clients mockups with styled fonts and plan ahead for how you would like your fonts to display on the various devices that won’t be capable of displaying your custom fonts.



No comments yet. You should be kind and add one!
By submitting a comment you grant Oturia a perpetual license to reproduce your words and name/web site in attribution. Inappropriate and irrelevant comments will be removed at an admin’s discretion. Your email is used for verification purposes only, it will never be shared.