SXSW: Web Typography and @font-face

Mar 31 2009

What are we even talking about?

Web Typography: Quit Bitchin’ and Get Your Glyph On was a popular panel that discussed limitations of web typography, myths about web typography and how to dispel them, and talked about overcoming constraints on the web to create typographically beautiful websites.

What is all the fuss about fonts on the web?

The first question the panelists were asked was, “Why are designers still bitching about typography?” After the giggles subsided, the top reasons they gave were:

  • frustration stemming from having such a limited palette of available fonts
  • the complexity and consistency involved in getting your type to render as intended

Basically, type on the web can be a pain in the ass. There are a decent amount of web fonts, but not all are attractive (Papyrus, anyone?), sometimes you have to use the corporate font specified in a client’s brand guidelines, and regardless what you do, everything can still shift around. A user could increase their font size or have a different default font specified for their system and throw off your whole groove.

Are there solutions?

There are several. Many people make their fancy titles into images, which does work, but then you’re faced with how to keep that text on the page for SEO; others use an image-replacement method like SIFR, but that involves Flash and can get pretty tricky in terms of line-height and making sure it doesn’t do something funky with punctuation or line wrapping. The “new” thing on the scene is to try out @font-face.

What is @font-face?

@font-face is a CSS property that has been around since 1998 (!) that allows you to “embed” a font so that you can call it using normal CSS font-family properties. Both Microsoft and Netscape adopted this CSS rule at the time, but each browser wanted a different font file type (EOT versus TrueDoc) and neither supported TrueType font files.

As Jon Tan explains:

That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

@font-face is pretty simple to implement once you have the proper file types:

@font-face {
	font-family: "Fontin Sans";
	src: url("http://server1.com/FontinSansR.otf");
}

h1, h2, h3 {
	font-family: 'Fontin Sans', Georgia, serif;
}

And then for IE 4-7:

<!--[if IE]>
<style type="text/css" media="screen">
	@font-face{
		font-family: 'Fontin Sans';
		src: url('Fontin-Sans.eot');
	}
</style>
<![endif]-->

You embed the font and give it a name, and then use it like you would any other font. Here, it’s named “Fontin Sans” but you could name it “Sparkly Unicorns” as long as that’s how you refer to it in the second CSS rule where you actually specify which font you want.

If you use one of the browsers (Safari!) that supports this, you can view an example »

Why should we use it?

Because it’s awesome! No, really. It’s nice because it lets your browser treat the font like any other font on your system. Copy wasn’t meant to end up as background images! It doesn’t require Flash! Plus, it’s been around forever without a lot of people using it, and if we start pushing the envelope by using it and voicing our concerns regarding its implementation, its situation may start to improve.

Why shouldn’t we use it? Are there problems?

The problems with using @font-face seem to be:

  • Legal issues stemming from font licensing

    There aren’t a ton of fonts that allow embedding via @font-face. Some more astute type foundries (like H&FJ, in paragraph 3.1 in their EULA) have used their licensing and terms of use to explicitly forbid the embedding of their fonts in this manner. Now, while this is decidedly not awesome for web designers or developers, it is in fact a step forward, because at least they know about it enough to recognize that it is a possibility.

    The other problem is the issue of redistribution. Most font licenses forbid unauthorized redistribution, and if you happen to use @font-face to embed your font, any Joe Q. InternetUser can come in, follow that link, and download the very expensive font (that you paid for!) for free. This is obviously not ideal for anyone except Joe Q. InternetUser. The panelists suggested that in order to protect yourself, you should set up your .htaccess file to forbid hotlinking or direct access to that font file, and then explicitly state in your site’s Terms of Use that downloading the font is unacceptable and if someone does manage to circumvent your .htaccess protection, that it is a violation of your Terms of Use. This is not foolproof, but it does show that you are making a concerted effort not only to protect yourself, but to protect the intellectual property of the type foundry from which you purchased the font. A determined thief would have to jump through several hoops to get at your font, and at that point it becomes obvious that you were trying to protect it and they are in the wrong.

  • Browser support

    Unsurprising, but as-is, this works in Safari 3 and Opera 10. It works in Firefox 3.1 beta but not Firefox 3. If you manage to create your special EOT file for IE, it will work in IE 4 through 7 but not IE 8.

    There are also some rendering issues. Safari will wait until the whole font file downloads before displaying any of the text using that font on the site, so if you’re using it for body copy, all your text may be invisible until that file finishes downloading. There is also no jQuery callback, so if you want to test to see if everything has loaded before you call a jQuery function, it does not include @font-face loading in that test.

  • Creating the EOT file for IE

    There is a program called WEFT that converts a TrueType font file to an OpenType font file to an EOT font file for Internet Explorer to use. Why it cannot do it straight from an OT to an EOT, I do not know. The program is free to download but is purportedly a total pain to use. In that same Jon Tan post, he discusses what a nightmare WEFT is and offers some helpful tips for getting it to create your file.

What are our next steps?

Trying it out! The panel set up a website called SXSW Typography where they posted a ton of resources and their downloadable slides. One of the best resources in their sidebar is Jon Tan’s experimentation with @font-face. It offers instructions as well as history and tips. There is also a website with a list of embeddable fonts.

The prevailing attitude in the panel (and in other places at the conference where I heard it mentioned) was that we need to keep pushing things forward. If @font-face doesn’t have the pervasiveness or the correct implementation right now, it’s not a problem since so few people use it, so we need to MAKE it a problem. Go out, experiment, push the envelope, and get your glyph on!

Posted by Meggan at 10:33 AM

Published in Events on Tuesday, March 31st, 2009

Tags: ,

2 Responses

  1. 1
    Mick says:

    Thanks for the info regarding IE8 not supporting embedded fonts. I recently got a new computer and noticed my embedded web site fonts do not display on it, but did on my older computer which did not have IE8. I initially assumed it was Vista causing the problems. Any idea when IE8 may support embedded fonts?

    Mick


  2. 2
    Meggan says:

    Hi Mick,

    Unfortunately, I don’t actually know when IE8 might support embedded fonts. I know Microsoft keeps an IE dev blog here, which would be where I’d assume they’d announce it if/when it happens.

    Thanks for stopping by!