Today I ran into a problem that I learned is quite common when using @font-face web fonts. For some reason Google Chrome, particularly on Windows, like to totally fuck with your fonts and display them all jaggedy. This came as a huge shock as things were looking perfect in Chrome on Mac and every other browser on every other platform including Internet Explorer 7, 8, and 9. Luckily I’m not the first person to have had this problem so I’ll share the solution again here for anyone who needs it after the jump.
The solution is quite simple. Chrome uses the SVG file to render web fonts and doesn’t yet support True Type fonts. Using workarounds like shadows and text transforms are kind of ugly hacks and are far more brittle than this solution. The way to fix broken @font-face fonts in Chrome is to declare it before the
.ttf versions in your
Standard Cross-Browser Webfont Implementation
1 2 3 4 5 6 7 8
Notice that the SVG file comes last in the standard implementation.
Font-face with the Chrome Fix
1 2 3 4 5 6 7 8
In this new implementation we declare the SVG file before the woff and ttf files and it fixes it! But there’s a catch! See that hash after the file name followed by the font’s name? Failing to include that part may cause this code not to work and you can’t just put any font name after that hash symbol. If you open your font’s SVG file, near the top you’ll see some code that looks like
<font id="fontName" ...>. That’s where you find the SVG name of the font and that’s what you put after the hash. It’s easy to assume that the font name or file name will be the font ID but it isn’t always necessarily and while I was trying to get Fanwood to work properly I found this out the hard way.