Google Fonts Failing For Internet Explorer Users

Jan 10, 2011

If Google isn’t going to take web fonts seriously, they should stay away. Slapping on a “Beta” label doesn’t excuse sloppiness or, worse, pursuing a hidden competitive agenda at the expense of users and developers. Now, I can’t know if Google Fonts is shortchanging IE users intentionally, but in light of the controversy over, say, Chrome Frame, you have to wonder.

Here’s what’s going on:

Jerrold Maddox, art professor, teacher of new media design at Penn State University, and a fellow member of ATYPI, sent me an email last Friday asking why an italic font – being served by Google – wasn’t showing up on his iPad.
( Jerry’s heavily into HTML as a platform for ebooks. The book that prompted his question, is here.)

The font is OFL Sorts Mills Goudy TT which comes in a Regular and an Italic. First, I looked in Internet Explorer. (IE users are still, conservatively, 60% of browser users. And yes, I am one of the great unwashed.)
Well, the italic wasn’t showing up in IE, either. IE was synthesizing the italic. In fact, on the specimen page for the font at Google, IE synthesizes it there, too. You can take a look.
What’s going on?

As it turns out, if you specify both regular and italic members of a font-family, Google doesn’t send more than the first one, the Regular, to IE. This is by design, not a malfunction. A quick test of two other fonts – Droid Serif and Tinos – gave the same result. And you can see it on the specimen pages.

You can test this by inserting this line into your style sheet:

@import url(http://fonts.googleapis.com/css?family=OFL+Sorts+Mill+Goudy+TT:regular,italic);

Alternatively, keying the URL into the address bar will show you the CSS being inserted by the @import declaration for the particular browser you are using.

Google fonts does not insert the CSS for the italic when it sniffs Internet Explorer. In fairness, I scoured the Google Fonts API documentation for any description of this behavior but there was nothing.
Internet Explorer has supported the use of font-families for over ten years. It’s well documented at EOTFAST. I know because I wrote it. (BTW – EOTFAST will soon be upgraded to include an EOTFAST 2.0. Plus additional tools and expanded tips and documentation. Stay tuned.)

Beta Not Use Google Fonts, Because There’s More Wrong

I wish this was the only defect in Google’s font effort. It isn’t.

  • Ordinary characters may be missing from the font:
    For example, the font Tinos is missing something as basic as a semi-colon. And yet, the character list leads you to believe that it’s there. (If you look at the character list closely, you can see that the style of the colon and semi-colon are different. It’s probably the fallback font peeking through.)
    Here are screenshots:
     FontLab shows the missing glyph.
     See the difference?
  • Google’s CSS Syntax Can Mess You Up:
    Best practices are being ignored. See Jonathan Snook’s post here, and this Typophile thread here for an in-depth explanation of why the local() descriptor should not be used to specify a locally installed font except in very special circumstances. (Normally, it’s used as a mask to prevent unwanted http requests in IE.) The Tinos font is the perfect example of why this is so.
    Scenario: Maybe the developer wants to make some complimentary images in Photoshop using Tinos and installs this version of the font – without the semi-colon – in the operating system. Well, unless you’ve figured out a way to push down font updates from the browser into the Windows fonts folder, with the CSS syntax as it’s now being delivered, forevermore on that developer’s machine, Tinos will continue to appear without a semi-colon. It will not have been updated with the fix.
    Message to Google Fonts: if you’re going to take a “we’ll fix it later” approach, please think through how and to whom those later fixes will be delivered. And if delivery is even possible except by Federal Express.
  • The font may contain unhinted glyphs: For example, the ASCII characters in Sort’s Mill Goudy are all hinted and look OK in the Windows GDI rasterizer. But many, many of the non-English glyphs and all of the Small-Caps apparently, are not hinted. If your web site is in French or Spanish you may be in for a whole lot of ugly.

It’s A Matter Of Trust.

This is Google, not a font services start-up out of nowhere. Developers are still very much strangers to using web fonts and @font-face and when Google brands an effort with their name, that creates expectations. Dabbling – just dipping a toe in the water – without the seriousness of at least some minimal quality control or, in the absence of that, some additional caveats and added transparency, is not a contribution. It’s just messing with people’s heads. And some fine-print disclaimer somewhere doesn’t change that.
I trust Google for Analytics and all kinds of other things. I am a great admirer of the Google Books project. And Google, the company, in general. But for web fonts today? Fuggedaboutit!

And, oh, BTW – the italic wasn’t showing up on Jerry’s iPad because he hadn’t as yet upgraded to the new OS with support for web fonts in the TrueType format.

Case closed.

Sharing Options:

Leave a Comment

Previous post:

Next post: