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.
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.
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.
PHP and backend font embedding is obsolete; use the more modern methods below.
Enter sIFR 2 and Flash embedding
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.
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.
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.
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
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.
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
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 a Perl module.
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.
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-family: "Robson Celtic";
Afterwards the font can be used as normal within the CSS:
font-family: "Robson Celtic";
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.
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.