We've generated a custom font by picking a few FontAwesome symbols and uploading our own custom SVG glyph. The app is a rich web app based on the Dojo framework and using Stylus to generate the CSS, serving the app from IIS 7. It has passed our QA test procedure on pretty much every browser and environment you could care to mention, except one QA guy's Win XP installation on Chrome. Firefox and IE on that same machine work fine.
This one Chrome browser shows the familiar box icon, as if the font file wasn't found. However, the .woff file is seen loading fine in the Net pane, with good file length, Content-Type (woff-font), etc. Loading the demo.html file that comes with the icomoon download renders the fonts fine.
We cannot for the life of us figure out why the demo file would render properly, but our app not. It is only a problem on this one machine, Chrome on other WinXP, Win 7, Win 8, Win 2008, and Linux machines render fine.
Our solution has been to remove the woff font spec from the CSS, so we're left with the eot, ttf, svg portions. This makes Chrome and Firefox fall back to TTF rendering, which works fine. So, we are left with this:
@font-face {
font-family: 'ourapp';
src:url('fonts/ourapp/fonts/ourapp.eot');
src:url('fonts/ourapp/fonts/ourapp.eot?#iefix') format('embedded-opentype'),
url('fonts/ourapp/fonts/ourapp.ttf') format('truetype'),
url('fonts/ourapp/fonts/ourapp.svg#ourapp') format('svg');
// temporarily removed while QAT Chrome is misbehaving url('fonts/ourapp/fonts/ourapp.woff') format('woff'),
font-weight: normal;
font-style: normal;
}
We have tried messing around with different MIME types, moving the icomoon CSS to the start of our CSS, putting quotes rather than apostrophes around the font family name, and so on, to no avail. We've turned the ClearType option on and off, and tried the Chrome dev tool Settings to turn rendering acceleration etc off. We've had several very experienced web developers look over this but we can't see anything wrong. The HTTP request for the woff file seems fine, the ETag is good, no CSS errors are reported when that filter is enabled in the Console. We cannot reproduce the problem on another machine at will.
Can anyone suggest why a woff file might be downloaded into Chrome and the CSS rules be present to use it, but it not actually render properly? It has us beat, for now.