Spruce It Up


Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

David Calhoun

Thanks for the tips – this is very helpful!

The flash of unstyled text is probably my biggest gripe with font-face, apart from the actual weight payload required.

I knew base64 encoding in the CSS was possible, but I didn’t like that option as the fonts end up being very large, like you said. The font optimization makes sense, assuming you don’t change the text often. If you do need to change the text, you will have to add more characters and reoptimize the font, which I could imagine could be a bit of a pain.

Mark Brown

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 ;)

Derek Anderson

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…

@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.


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.

Colin Williams

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.

Jonathan Snook

@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.

Impress us

Be friendly / use Textile