Mar 28, 2014
Update: This is actually all better now, and no longer relevant. How the times change!

font_bad_1Google Fonts is a fantastic service, but there is one major problem with using it:  Your custom fonts will render like crap in Chrome for Windows–hideous, deal-breaking crap.  If you’re familiar with the effect, you’ll recognize immediately that the word “Community” is a Google font.

It looks fine on Linux and Mac.  Looks fine in Firefox and Opera.  Hell, it even looks fine on IE 8.

Common wisdom seems to be to apply antialiasing with a webkit-specific CSS property, assign a text-shadow, or even slightly rotate the text.  You can also load the fonts from your own hosting using @font-face and throwing four or five formats out in a particular order so that each browser latches onto the correct one for it (the drawback being that in all but the most rare instances, you’re loading each of your fonts twice, and from your own server).  Even then you’re betting on browsers acting predictably quirky across versions, though, and if the browser pulls the wrong file, guess what:  Your fonts look like crap.

Technically there is no way for you as a web developer or designer to solve this, but from a practical perspective you can patch it up pretty nicely.

A light, easy way of addressing this issue without abandoning Google Fonts is to use Google Fonts normally, acquire the SVG file for your font (try pulling it from one of Font Squirrel‘s kits), and then apply that SVG using @font-face if a media query detects Webkit.

Say we wanted to use the Google Font “Lora.”  First, load it normally in your CSS:

@import url(http://fonts.googleapis.com/css?family=Lora);

Then, insert a media query that will detect webkit, followed by a @font-face declaration for Lora from an SVG on your server:

Other browsers will be unaffected and load the initial Google font, while Chrome will use the specified SVG instead, resulting in text that may not be perfect, but will be quite a lot better:

font_good_1

Fork me on GitHub