I just wrote the following for our marketing team to understand how to sell font solutions to our clients. If you have any feedback, I would love to hear it in the comments section!
When a client’s design calls for a custom font in the headlines, there are a variety of solutions we can recommend, ranging from sIFR to image replacement. Each solution (detailed below) offers advantages and disadvantages, so the correct choice may vary from client to client. In general, however, @font-face will provide the best long-term solution and ease of development.
CSS3 adds the ability to serve a custom font from the server. It works beautifully, and is well supported in modern browsers*, including IE6+, FF3.5+, Safari 4+, and Chrome 4+. This is the way custom fonts should be handled. That said, there’s one barrier to adoption: Since the font is hosted on the server, you must have a font that is licensed by the foundry (the company that made the font) for web use. There are many free, open-source* fonts available, and a growing library of fonts that can be licensed* directly from the foundry. The cost for a web license (which is frequently separate from the regular cost of the font) ranges widely depending on the foundry.
We encourage our clients to use this method, despite the extra cost, as it is legal, accessible, requires no extra development time, and is the most future-proof solution. Compared to @font-face embedding, every other solution listed here will cost extra (in the form of development time). By purchasing the font license, they are supporting the foundry that made their font, and making their website more adaptable for future edits.
Additionally, for any advanced font styling such as gradient fills, drop-shadows, glows, backgrounds, etc., @font-face is the only solution. You simply cannot recreate these advanced CSS styles on dynamic headlines through sIFR or cufón.
Pros: native font rendering, accessibility, graceful degradation, and advanced font-styling through CSS.
Cons: must use an open-source font, or purchase a license for a commercial font.
Cost: just the cost of the font license. no extra development cost.
Pros: handles all the @font-face embedding and licensing for you. Likely cheaper than a license direct from the foundry.
Cost: depends on website traffic – ranges from $25 to $99/year
sIFR – not recommended
Pros: graceful degradation, widespread flash adoption, and legal to use with any font.
Cons: complicated and limited. Basic text replacement works great, but more complicated things like nested styles within the headline are difficult or impossible. Project is no longer being developed, and is poorly supported.
Cost: At least 3 hours of front-end development PER headline style, and further QA, since the site now has to be tested with and without flash.
cufón – not recommended
Pros: less complex than sifr
Cons: accessibility concerns, and since the font isn’t embedded in flash, it may not be legal unless you have a license from the font foundry.
Image replacement – not recommended
Using CSS, we replace individual headlines with images containing that headline set in the client’s font. This solution is time-consuming and difficult to edit, but works well on sites with a small number of headlines that don’t need to be edited very often.
Pros: gives the client exactly what’s represented in the comp.
Cons: requires lots of image production time to create every headline image, and corresponding CSS production time to write code to replace all those headlines with their images. Making edits in the future is difficult, because someone will need to make a new image and edit the CSS. Likely impossible to implement in a dynamic CMS like Drupal.
Cost: 10 minutes per headline, minimum.
Use native fonts instead – not recommended
This isn’t really a solution, since it doesn’t use the client’s font. I’ve just included it for completeness’ sake. This approach means that we ignore the custom fonts and use one of the limited set of “native” fonts instead. In practice, this means using Arial for sans-serif fonts and Georgia or Times New Roman for serif. If the client’s font isn’t very distinct, then this can be a good choice.
Pros: requires no development time at all.
Cons: does not use the client’s font.