http://jonraasch.com/blog/embedding-custom-fonts
It’s happened more times than I can remember: I finish a front-end for a site, using custom font embedding, pixel-for-pixel CSS, the works. But when it comes time for design review, the designer moans: “Can you make that font a bit heavier, it doesn’t look organic!” Assuming that “organic” really means something and ignoring that the font looks 99% identical to Helvetica, I have to trust their better judgement.
Has this happened to you? Well it’s time for us developers to stop complaining about web typography. Custom font embedding has been around for years, and it has finally gotten to the point that typography nerds can be equally happy with the fonts on a website as they are with the Photoshop comps. Many of the things that were a total pain to support previously have become a piece of cake. Leading, kerning, and all the major typography buzzwords have been handled for some time. Even drop shadows and Photoshop-style font rasterization options such as ’strong’ and ‘crisp’ are now fully supportable.
So let’s make sure that we don’t become dinosaur developers, and get up on these modern methods of custom font embedding.
In this article we’ll cover all types of font embedding, from older image replacement methodsto embedding fonts with Flash, as well as native browser methods and even fullJavascript font support with the new script Typeface.js.
Dynamic image replacement (The old way)
In order to fully appreciate how far custom font embedding has come, it is important to learn a bit about its history. However if you really don’t care, feel free to skip to the next section, since these methods are all but obsolete.
A few years ago the primary way to embed non-web-safe fonts on a website was more complex. Basically, the backend would use a graphic script like ImageMagick to convert a font file into an image for phrases on the fly. At the browser level, Javascript would then replace that phrase in the HTML with the image. See an example here.
Drawbacks:
The main drawback to this method of custom font embedding is that it’s very resource heavy. While the importance of caching for these early scripts is obvious, even then it only made sense to replace a few headings here and there, and totally dynamic content could present a processing problem.
Additionally, once the Javascript kicked in and replaced the given text, the user would see the change flicker in their browser, a problem amplified by slower computers. Finally, since this method would essentially take the font and slice it up into a series of images, only the very basic aspects of the font were supported. If, for instance, you wanted to use bolding, the script would have to use a new font file, an additional cache for those phrases, etc.
The Verdict:
PHP and backend font embedding is obsolete; use the more modern methods below.
Enter sIFR 2 and Flash embedding
While the original methods of custom font support are fairly obsolete, they did pave the way for more modern methods, one of which is Flash based embedding. Fully supportable on regular HTML pages, Flash embedding draws on a lot of the same concepts as image replacement scripts: custom font areas are flagged within the HTML and Javascript is used to replace the original websafe text with the custom font. The only difference is with Flash embedding, Flash is used for the font support, rather than a backend ImageMagick script.
Supporting custom fonts using Flash makes sense for a variety of reasons. Flash natively supports custom fonts, which are embedded within the SWF file. Since the SWF is compiled, the font is furthermore inaccessible to end users, thus eliminating any licensing concerns. Also, since the Flash replacement occurs entirely on the front-end, it can be achieved without backend access and more importantly without a large toll on the server. For all these reasons, I switched immediately to Flash font support with sIFR 2.
sIFR 2 supports a variety of typography options beyond simply embedding the font. Italics, bolding and underlining can all be achieved with a single file. Beyond these there are controls for letter spacing (kerning), line-height (leading) and other common typography requests. Additionally, sIFR 2 uses CSS 3 selectors to streamline the flagging of replacement text.
Drawbacks:
While sIFR 2 is a big step up from dynamic image replacement, it also has a variety of drawbacks. The main problem with sIFR 2 is that fonts tend to expand to fit the area of the SWF, which is determined by the dimensions of the original HTML text. For most developers this doesn’t present a huge problem, since font sizes are fairly easy to hack into place using line-height and other CSS tricks for the HTML text. However, for doing pixel perfect renditions of designer comps sIFR 2 is a total nightmare. I’ve pulled my hair out time and again with sIFR 2, with designers never seeming 100% happy with the end result.
The Verdict:
sIFR 2 is a pretty decent option, but sIFR 3 is better.
sIFR 3 solves sIFR 2’s bugs and more
Thankfully, almost all my font replacement woes were resolved with the release of sIFR 3. While still officially in beta, sIFR 3’s advancements over sIFR 2 can not be ignored, and after extensive testing I am now using it in production.
Most importantly, sIFR 3 fixes the font-expansion issue described above, rendering font sizes with either a user-generated Javascript variable or the native font size of the HTML text by default. Like sIFR 2, sIFR 3 easily supports a variety of typography options. Additionally, sIFR 3 has made the styling of custom embedded fonts much easier, using more intuitive CSS controls and selectors.
Finally, sIFR 3 introduces a wider variety of styling options, offering drop shadows, outerglow and gradients on embedded text. See the sIFR docs for more info
Drawbacks:
The main drawback to sIFR 3 is that it still relies on replacing fonts using Javascript. Although it has methods to ensure that the user doesn’t see the change as a flicker, the user must still wait for the page to load, and then wait for the custom fonts. Furthermore, sIFR 3 requires Flash Player 8 or higher, however this is a non-issue for the vast majority of users. Finally, since the font is still being replaced dynamically, sIFR 3 is a bit cumbersome to use for all the fonts on a page.
I have encountered a few minor bugs with sIFR 3, mostly surrounding the wrapping of text in floated content, however I assume these will be cleared up with the full release.
The Verdict:
All things considered sIFR 3 is my favorite method for embedding custom fonts: feature-rich and well supported, it is currently the most headache-free option.
The new kid on the block: Typeface.js
Typeface.js is an interesting new script that embeds custom fonts using nothing other than Javascript. It provides a number of typography customization options, covering most of the basics such as font-weight, color and line-height in addition to offering some advanced typography options like font-stretch and letter-spacing.
While not the most feature-rich method, Typeface.js has the advantage of not requiring Flash Player to run. In addition, preparing fonts for use with Typeface.js is easier than with sIFR: instead of building a font file in Flash, fonts can be converted using either an online tool or aPerl module.
Drawbacks:
Typeface.js is still in its infancy and is unfortunately unusable in my opinion. While officially supporting all modern browsers, cross-browser implementation is spotty, with fonts rendering differently across different browsers. Additionally, it takes a long time to load in IE, and fonts are only selectable in browsers that support canvas.
Finally, the biggest drawback to embedding fonts with Typeface.js is licensing. While Flash embedding methods compile font files into the SWF, Typeface.js still exposes the font file to the end user. And as the Typeface.js website warns, “Many font vendors specifically prohibit redistribution and embedding of their fonts.” So make sure you have proper licensing before you use a font with Typeface.js.
The Verdict:
Typeface.js is an interesting project although not yet ready for use in production. In the future it may become a viable option for font embedding, however only with redistributable fonts.
And why don’t we just do it this way? (Native browser methods)
With the variety of methods for embedding custom fonts, it’s easy to forget that it shouldn’t be all that difficult. Why can’t we just pass the font file to the browser, and then allow it to render the page accordingly? Well it turns out in a lot of cases you can.
Custom font embedding has been supported by native browser methods since IE 4. Here Microsoft came up with Embedded Open Type (EOT), a proprietary file type that got around font licensing issues. To encourage EOT use, Microsoft also released a conversion tool: WEFT.
Embedding fonts through native browser methods is such a good idea that it was written into the CSS2 specifications by the W3C and is already being supported by Safari as well as betas for Firefox and Opera. However the EOT format is owned by Microsoft.
How to use it:
In browsers that support the font-face property, custom fonts can be embedded with a small chunk of CSS:
@font-face {
font-family: "Robson Celtic";
src: url("http://site/fonts/rob-celt")
}
Afterwards the font can be used as normal within the CSS:
p {
font-family: "Robson Celtic";
font-size: 1em;
}
Isn’t that awesome? I mean no Javascript, no Flash, nothing but straightup markup. It’s really the way it should be, but unfortuantely we don’t live in a perfect world.
Drawbacks:
The main drawback to this method is cross-browser support. While supported by all modern IEs as well as Safari, current releases of Firefox and Opera are left out.
Additionally, since the proprietary EOT format only works in IE, different font files need to be passed to IE and the other browsers. Finally, with non-IE browsers developers run into the same licensing issues as with Typeface.js, where the font is exposed to the end user so only appropriately licensed fonts can be used.
The Verdict:
I really wish this were a viable option, however with the lack of current browser support, these native methods seem a long way off. Additionally, a new open-source or more freely distributed font format than EOT will need to be supported before developers can use browser-based methods for all fonts regardless of license.
So stick with sIFR 3 for now, it is currently the best method for embedding custom fonts.