Will Font Embedding Ever Become A Reality?

Avatar of Chris Coyier
Chris Coyier on (Updated on )

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

I have to admit I don’t have my head fully wrapped around this whole font-embedding controversy. At it’s root, it comes from us web designers being frustrated by the lack of options font options for our web pages. We want more, the “core 10” are just too limiting. Ideally, we’d like to use any font we want without resorting to alternative methods like sIFR, FLIR, or simply just using images.

This where the @font-face CSS attribute comes into play. It’s actually a CSS2 recommendation, but no two browser supported it in the same way making it kind of useless. (It’s gone in 2.1) Here is the theory:

@font-face {
  font-family: "SuperSweetFont";
  src: url(http://www.yourdomain.com/fonts/sweet/supersweetfont.ttf) format("truetype");
h1 { 
  font-family: "SuperSweetFont", sans-serif;

I believe this is where the controversy starts. In order for this to work, that font file needs to be hosted in a publically-accessible directory. This means that fonts will be just as easy to “steal” as a CSS file or an image is. Just figure out the path, pop it in a web browser and save it. We’ve gotten used to this when it comes to the code we write and the images we create. Entire web pages can be saved directory off the web with almost no effort whatsoever. But when it comes to fonts, it gets a little trickier. Font foundries charge big money for their fonts, and they don’t want them to be so easy to steal.

Major type foundry Hoefler & Frere-Jones straight up forbids it in their EULA:

The emerging @font-face tag within Cascading Style Sheets (CSS) will hopefully lead to a secure technology that allows fonts to be used in web pages. But at this time, no such security measures exist, so the use of this tag with our fonts constitutes the illegal distribution of the font software. This type of use is therefore specifically prohibited under our End-User License Agreement.

The controversy heightens even more when ways to protect these font files are discussed. It makes sense on some levels to use some form of DRM (Digital Rights Management) to protected them. Of couse, that acronym makes the hairs on a lot of folks neck stand up. Microsoft was on-board with a company named Ascender Corporation who can supposedly provide font-licensing servers that would work on the external internet. I can’t tell you much more, as I don’t know much more, but I’ve read some positive things that this kind of technology, while technically DRM, could really be a good solution.

More controversy yet comes from some designers calling for the big dogs to just release a number of high quality fonts free for public use.

Please consider releasing eight to twelve core fonts into the public domain. The amount of revenue lost from a small core set of fonts surely can’t have a significant impact on Adobe’s bottom line. And the gesture of releasing such a set into the public domain would have many positive ripple effects for years to come.

I’m sure many designers have a different list of what those eight might be. I know my list would include the likes of Adobe Caslon Pro, Adobe Jenson Pro, Franklin Gothic, Frutiger, Futura, Gill Sans, Helvetica Neue, Univers and your new namesake, Warnock Pro.

Personally I think begging for fonts isn’t quite the long-term solution we need. Even if that dream were to come true, it would take quite a while for major operating system creators to start shipping them by default and there is certainly no guarantee of that. We could embed them in the short-term, but I’m not sure that’s the idea here. Imagine how many duplicate cached copies of Futura you would accumulate in a day.

If the @font-face thing does solidify itself as the way we’ll be handling embeddable fonts in the future, more problems await. Perhaps most significantly, IE will only be supporting this “EOT” format, while all the other browsers are using TrueType. Right there we are back to the “bad old days”, having to (at best) have two different CSS statements to support different browsers. Not good. I am actually a little unclear here if this is still the current state of affairs, so please feel free to enlighten me.

So when we boil it all down, these are the hurdles as I see it:

  • If the spec for @font-face stays the way it is, it’s still going to take time for enough browsers to support it that it will be worth using.
  • Most great fonts that you would actually want to use this way are illegal to embed under current EULAs. Most fonts that are legal to use suck.
  • There needs to be a push (featuring some kind of compelling reason) to get all browsers to support the same font format.
  • This may lead to a proliferation of poor taste in fonts the likes of which we’ve never seen. Of course we “can’t blame the poor carpentry on the nails”, but it’s still worth thinking about.

Regarding the DRM, there has been some murmurs that there has to be a better way. I agree wholeheartedly. This comment from Jon Hicks on this article I think has the right idea:

To get around the piracy issue, I imagined a system similar to Google Maps. You get a unique key from a type foundry that only works on certain domains, and hides the actual location of the font file.

I think the foundry that gets on to this first will be a winner.

Seriously, there has to be some kind of licensing system that only will serve up a font file with the correct combination of base URL and key. I this would be a killer solution for serving up high quality font while staying legal. However, this solution doesn’t prevent other illegal use, just enables good legal use.

So after all this, I’m still left a little confused. Will font embedding become a reality? In some ways it already is, and seeing limited browser support. In other ways, it’s a long way off.

More information

Jon Tan calls for a grassroots organization to handle universal web type.

A List Apart: CSS @ Ten: The Next Big Thing

“Embedded” Web Fonts Return. Uh-oh.