So, you are a web designer going about your daily life, struggling with IE 6, huffing about CSS 3/HTML 5, berating your designers for not using web-safe fonts, and there comes a brick hurling towards you named @font-face. You are dumbstruck. You have no idea what hit you. Everyone is asking about it, and you pretend to know about it. Then you quickly google for it and are hit with even more bricks. I was one such web designer and I spent 4 days in agony, learning about @font-face. I wrote this down, so that no other web designer has to face this torture anymore. So here is the “A to Z” of what @font-face means now and what it will mean for the future of web design.

Digital/Computer Fonts

Computer fonts are digital data files that are made up of a set of characters and glyphs to render text.

Copyright issues with Computer Fonts

The U.S. Copyright Office has declared typeface design cannot be copyrighted. (Some other countries do allow copyrighting of typeface designs). Hence, analog font designs (those metal characters) cannot be copyrighted.

However, all scalable digital fonts are treated as “Computer Programs” and hence come under the draconian DMCA. As they are treated as software, you only get a license to use the software following all the instructions of the font creator/seller. Almost all commercial licenses forbid you to share/link to fonts.

Font Embedding

Font embedding refers to technology that saves fonts (or subsets of fonts) inside document files. The aim of this is that recipients of the document can see it as it was designed, without having to have the fonts already installed on their computer.

- Older version of Electronic EULA Wiki

There are two major font formats: True Type and Open Type. Both support, “embedding protection” by having an “embed flag” that specifies what kind of embedding permission has been allowed by the font seller. The permissions available are:

Restricted License: This font cannot be modified or exchanged or embedded in any manner without first obtaining permission of the legal owner.

Preview & Print: This font may be embedded and temporarily loaded with a document on a remote computer. No editing of a document is allowed.

Editable: This font may be embedded and temporarily loaded with a document on a remote computer, and the document may be edited and the changes saved.

Installable: This font can be embedded and permanently loaded on a remote computer for use with the document. The user of the remote computer acquires the same rights and obligations as the original purchaser of the font.

- from Document Font Embedding
There has only been one case that has been brought to court which tested the usage of these embed flags. It was a case that Agfa Monotype brought against Adobe Systems for the software that Adobe produced which did not respect these embed flags. The court noted that embedding bits do not effectively control access to a protected work.

@font-face

Introduced in 1998 for CSS level 2, the first browser to implement it was IE 4 which used (and which IE 8 continues to use) a new format of font called EOT. It was introduced (without the EOT) in the CSS 3 Draft – mostly thanks to Håkon Wium Lie. Webkit (the web browser engine that powers Safari, Chrome) started supporting @font-face in October 2007, Firefox in October 2008, Opera 10 in December 2008. All of them do not recognize EOT format but only the existing popular True Type and Open Type formats.

How to use it?

It is quite simple. See the example below (from the CSS 3 draft) for a simple use case:

	
		@font-face {
		  font-family: Gentium;
		  src: url(http://site/fonts/Gentium.ttf);
		}

		p { font-family: Gentium, serif; }		
	

Read Paul Irish’s entry on how to use @font-face so that it works across all browsers that support it.

But there is no embed, you idiot!

Technically, @font-face only links to fonts, but the browsers would have to download those fonts and store it in the user's machine to render the HTML document. Hence, a lot of font developers treat @font-face font linking as font embedding.

Drawbacks of @font-face

Technically, you can use @font-face cross-browser right now! But there are a few issues with using @font-face:

• Many fonts of today are really huge, running into 2MB or more. So, users of your website need to wait till the font downloads. In Firefox 3.5, the users will see the web safe font (if you have declared it) first before it switches to the downloaded font. But, scarily, in Safari, you will see nothing, till the font loads (if it loads at all).
• Firefox implements a same-domain restriction on fonts, which means the font you use and the HTML file you use it on must be on the same domain name. You can overcome it by setting the HTTP Access Controls on the server where your fonts are stored.
• You can only use fonts which have been explicitly licensed for using with @font-face. You can find a those fonts in these sites: 1, 2, 3, 4.
• A lot of designers think @font-face will herald the return of the 90s design and the “downfall” of web design as we know it. Obviously, this is a silly conjecture, tools do not make a design.

What is this EOT?

Read this wikipedia entry on EOT and come back here.

Read it, why not just use EOT and be done with it?

The main objections that Firefox and Safari have to using EOT is the clause in the specification of EOT that states “If the font embedding bits do not provide permissions for embedding, the user agent shall not use the font.”

A lot of free software evangelists are against the idea of using the embed flag as DRM

Another objection is that the compression technology used by EOT is patented by Monotype Imaging. Monotype has claimed it will bring the MTX technology into public domain IF EOT gets adopted universally (a classic chicken-and-egg problem).

There is a proprietary Microsoft (windows-only) tool to generate EOTs, called WEFT and that tool does not convert Open Type fonts to EOT format, but the OTF fonts need to be converted first into True Type fonts (see Jon Tan’s great post on @ font-face). However, there is an alternative, as pointed out by Stefan van Zanden called ttf2eot that does the same without the frustration of WEFT. The last I checked, it seems like it does not output the root strings without which IE 7 and 8 cannot render EOT font. Stefan has a demo showcasing how the fonts work on most modern browsers.

EOT in it’s current incarnation, needs a URL to be supplied with the original font and the resulting EOT font will only work on those specific websites.

Recently, some research suggests that MTX compression has negligible effect on the file sizes of some ClearType fonts, and some other compression algorithms like LZMA seem to work better.

More articulate arguments against EOT are in this excellent Report on Font Embedding

So What Now?

Many people have suggested entirely new web formats to implement. Some major proposals that have gained prominence:

• EOT Lite This does away with the two most hated parts of EOT, compression and respecting the embed flag. So, it ends up like a wrapper around the font itself (Read more about EOT Lite here). The best part is, this will work with existing implementations of EOT in IEs. Not many type foundries are supporting this format though - mainly because of the removal of the recognition of the Embed Flag.

• webfont This has gained massive popularity recently. Webfont was first introduced here and refined here by Erik Van Blokland and Tal Leming. A font of this format will contain two files compressed (proposed to use zip compression):

  1. info.xml
  
  2. Font file
  
  
  

  The xml will have info on the font meta data like: creator, create date, font name, vendor name, vendor url, etc. The most controversial of these is the “allow” field — which is the same as an Embed Flag — in that meta data which is stated as optional, and is proposed that browsers use this information as they wish (either show it in the Page Info area, or explicitly deny fonts from rendering if the Embed Flag prohibits such use).

• ZOT has gained currency recently. The proposal is for a compression format (by Jonathan Kew) consists of a ZOTHeader, Tables Directory, and Font Tables. It allows a User Agent (e.g. a browser) to simply download the header and determine the number of tables required, and download only the necessary font tables (by looking up the Tables Directory) of the font to render the text.

• UPDATE on 7th Aug 2009: Jonathan Kew, Tal Leming, Erik Van Blokland have combined their proposals into a new WebOTF format that seems to have the support of representatives of most browsers. Seems like this format might just win.

OK. What can I do NOW?

You can use fonts from the Open Font Library.

You can also use commercial fonts that are aligned with Typekit. Typekit uses javascript to provide some basic protection against downloading these fonts directly. Another service similar to Typekit is Kernest, some comments in the www-font mailing list seem to suggest it is not ready for prime-time yet. But, you have two options, if you would like to go the javascript route.

Typotheque Font Foundry has announced a web font service which will provide both TTF and EOT fonts which are small and fast to load for a price. The service has not started yet. From the discussions on the www-font mailing list, it seems like Typotheque corrupts the NAME tables with referrer checking which prevents the font from being installed on a computer. I am unable to confirm if this is true. If you have tested their service, do let me know in the comments if it is.

Subscribe to the www-font mailing list and keep yourself updated. Or watch this blog (or my twitter stream) for BREAKING NEWS about Web fonts.

This current rage of Font Formats has been compared to the GIF controversy of yore. But, let’s hope this too will lead to something great.

Hopefully, all this information has still left your brain intact to process other crazy information about font-face that will emerge in the coming days. Whatever it is, the ways and methods of a web designer are on the verge of radical change. Yes we can!

Thanks to Bruce Lawson, Russ Weakley and Martin Kliehm for reviewing this article and correcting some facts.