Chrome 18, Corrupted text and Google Webfonts: A fix.

posted on April 4th, 2012 by Anthony

Yesterday I was working on a new design and installed the lovely Open Sans font on to my MacBook Pro. All was fine and I happily mocked up the design I was working on. Then I did some general mooching about the web and went to digest one of the many unread articles I have in my open tabs.

Except I couldn’t read it. I was confronted by body text that had blocky error characters instead of actual type.

UX Booth weirdness

 

Not very useful.

I know it had worked earlier in the day, so I started to dig around a bit. So I used the WhatFont? Chrome extsion to see what the offending font was. Ah ha! It was supposed to be Open Sans – the same font I had just installed and activated a few hours earlier.

Then digging in to the source code it was obvious to see that fonts were being served by Google Webfonts.

Bulletproof

That’s when I had a little tickle of a memory that local fonts can cause conflicts with the ones being served via @font-face if the names are the same. I also had a feeling Paul Irish’s ‘Bulletproof @font-face syntax‘ had something included in it to prevent this happening.

Sure enough there is the Smiley variation of the code that does just that.

Google Webfonts

The issue seems to especially effect fonts provided by the Google Webfonts service. So I did a bit more digging.

The code that Google Webfonts provides to users to use their fonts generally looks something like this:

<link href='http://fonts.googleapis.com/css?family=Crete+Round:400,400italic|Open+Sans:400,700,800' rel='stylesheet' type='text/css'>

It’s kept deliberately simple, and shields the user from the nitty gritty of the @font-face mechanics. You have to follow that url to find the actualy syntax that they are using. That translates to this:

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 700;
  src: local('Open Sans Bold'), local('OpenSans-Bold'), url('http://themes.googleusercontent.com/static/fonts/opensans/v6/k3k702ZOKiLJc3WVjuplzKRDOzjiPcYnFooOUGCOsRk.woff') format('woff');
}
@font-face {
  font-family: 'Crete Round';
  font-style: italic;
  font-weight: 400;
  src: local('Crete Round Italic'), local('CreteRound-Italic'), url('http://themes.googleusercontent.com/static/fonts/creteround/v2/5xAt7XK2vkUdjhGtt98unYo3ZslTYfJv0R05CazkwN8.woff') format('woff');
}
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url('http://themes.googleusercontent.com/static/fonts/opensans/v6/cJZKeOuBrn4kERxqtaUH3bO3LdcAZYWl9Si6vvxL-qU.woff') format('woff');
}
@font-face {
  font-family: 'Crete Round';
  font-style: normal;
  font-weight: 400;
  src: local('Crete Round'), local('CreteRound-Regular'), url('http://themes.googleusercontent.com/static/fonts/creteround/v2/ZCcPJiCGOzh84o2siPk48brIa-7acMAeDBVuclsi6Gc.woff') format('woff');
}
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 800;
  src: local('Open Sans Extrabold'), local('OpenSans-Extrabold'), url('http://themes.googleusercontent.com/static/fonts/opensans/v6/EInbV5DfGHOiMmvb1Xr-hqRDOzjiPcYnFooOUGCOsRk.woff') format('woff');
}


Which works fine in most cases.

Except, it seems, when you happen to be running Chrome 18, on OS X and with fonts installed on the system that have the same name as the ones Google Webfonts is referencing. Then the issues you see in the top image come in to play.

Solution

Fortunately it is remediable.

Use the url in your own piece of code that Google supplies you with, paste it into your browser address to view the @font-face code it is calling.

Copy and paste all the code into your main CSS file.

Find each piece of code that refers to local(‘YOURFONTNAME’) and replace YOURFONTNAME with the unicode character ☺.

Save it and remove the piece of code Google Webfonts gave you originally.

Now – fingers crossed – your fonts should be more Bulletproof.

It’s only an issue that seems to occur with OS X and Chrome 18 (with my very limited Twitter research). It’s probably a Chrome bug – but it makes sense to make your font code as robust as possible, especially as it has such drastic results on your sites content.

It’s certainly something to keep in mind if you are using the service.

Update: It seems this is possibly a temporary issue with the current build of Chrome. There will surely be an update rolled out soon that will fix it – but there’s no set period for when that might be. Certainly the latest version of Canary (the Chrome beta programme) doesn’t suffer from the issue. Though it should be said that is listed as v20…

Another thing that I should point out (as suggested by Dave Crossland @davelab6) with my fix is that it does break the bond between your site and Google’s Webfont service. They will automatically update their linked code over time when they update fonts, using this fix will stop that.

It’s up to you how deal with the issue – if you even need to!