I know this is old news and simple to fix, but recently I stumbled upon a new solution which also irons out some problems with the widely adopted original fix…

Background

Chrome has trouble rendering true type fonts on Windows OS, in particular with the anti-aliasing. This can leave your typography looking blurry and jagged, like the text on the left below (rollover to zoom coming soon)

Left: Normal chrome rendering. Right: Chrome rendering with fix in place.

The options

Call the svg version of the font before the woff version, as chrome renders svg much better. There are a couple of ways you can go about doing this:

1. Change your font stacking order to call the svg before the ttf and woff, for example:

   @font-face {
   font-family: ‘fontName’;
   src: url(‘font.eot’);
   src: url(‘font.eot?#iefix’) format(‘embedded-opentype’),
   url(‘font.svg#svgFontName’) format(‘svg’),
   url(‘font.woff’) format(‘woff’),
   url(‘font.ttf’)  format(‘truetype’);
   }
   

   Caveats

   This will cause Safari to download the svg first and then the woff, plus the svg is usually a bit heftier in file size. So an extra http request for Safari, and probably a beefy one too.

   I’ve seen people reporting spacing anomalies when serving the svg font to Chrome this way. I’ve not seen it myself but it’s something to bear in mind if you are choosing to go this route.

2. My preferred method use a media query to serve Chrome the svg:

   @media screen and (-webkit-min-device-pixel-ratio:0) {
     @font-face {
         font-family: ‘fontName’;
         src: url(‘font.svg#svgFontName’) format(‘svg’);
     }
   }
   

   This ensures Chrome gets the svg and those spacing anomalies are eliminated.

   Caveats

   None so far that I have found, apart from the extra code bloat but nothing to even think about, especially if you are minifying your code like the good coder you are.

Conclusion and gotchas

Serve Chrome the svg version of your font for typography utopia on windows devices.

Some things to watch out for:

• That #svgFontName in src: url(‘font.svg#svgFontName’) format(‘svg’); needs to match the ID of the font within the svg file as it can contain more than one font. Failure to do this will result in the browser not rendering the svg font.

  To check, open the svg font in notepad++ or similar, look for <font id=" and make sure the ID in there matches the #svgFontName in your css. +1 to the guys at fontspring for this one.

• native browser elements like form controls don’t render the svg font very well so for those you will have to revert to your backup web-safe font.

• While we’re on the subject of native elements, they also don’t pickup -webkit-font-smoothing if you have specified it ‘globally’ in the html or body elements. Again, you will just have to re-target those elements specifically i.e.

  .button_primary { -webkit-font-smoothing: antialiased; }