Thanks for the tip. I’ve become fascinated by recent developments with @font-face and the WOF format and SVG in particular. I’m really glad to see font foundries getting on board with font embedding on the web. It’s a great thing for the web and Typography in general.

For your example with the Goudy ampersand it would probably achieve the smallest possible bandwidth as raw outline paths in SVG – But that wouldn’t be as simple to implement ;)

Very nice! I didn’t know about the online tool to do the hard work for you, that really helps!

Also worth mentioning: Base64-encoded data URIs are 1/3 larger in size than their binary equivalent, so beware if you are encoding anything rather large, as it will get larger…

Elegant! I like the use of the fallback. Thank you for the tip!

Um, I thought data uris didn’t work in IE 7 an below, and even has his quirks in IE8.
But great article as always, Mr. Snook.

Thanks for this — making @font-face actually usable is the difficult bit.

And the way you’ve got rid of the span around the ampersand is really inventive.

For me, using Safari 4, the Goudy Bookletter ampersand didn’t show until I edited the HTML to ‘&’ and not ‘&’.

@Michael Hessling: I just tested it in Safari 4.0.4 in Windows and it works fine.

@Osvaldas: It’s in the article (just before the last image): 3KB.

@Osvaldas — Generate your font and what are you left with? 3KB.

When I convert Arial Black to svg my layout is getting mangled if I only choose the individual characters I need before conversion. When I select all uppercase and numerals the layout is fine. There are no spaces where the font is being used, tested with the space character anyway. Can anyone guess what might be happening? I’m using the font for simple one-letter/numeral headings.

Great tips in here, Jonathan. Short and sweet. Thanks!

I just can’t seem to get as giddy as everyone else about @font-face embedding. The straight-forward implementation is only good for FF and Safari users. You need to make an EOT for IE and it typically looks really shitty because most fonts aren’t designed for ClearType (a problem for all Windows users, really), and then you need SVG to get Chrome to behave.

Screw it. Cufon for me for the foreseeable future.

@Derek Anderson: Base64 encoding increases the size by about 1/3, yes, but gzip compression brings the size down to about what it was before.

@Colin Williams: That’s why I mention the Font Generator. It’s a one-step process to generate an EOT, SVG, and modified TTF/OTF file. It even gives you a CSS file to work with. Yes, there can be rendering issues and Ethan from Font Squirrel (among a few others) have been working hard to understand these issues to produce better output.

@David Rojas: IE7 doesn’t support data URIs but it also doesn’t support TTF font embedding, just EOT. Therefore, the data URI approach is intended for all browsers but IE (even IE8). Those browsers would still continue to access the EOT file from the server. Subsetting would still reduce the overhead though, and this is still an important takeaway from this article.