This is a years-old bug in Google Chrome on Windows which leaves designers/developers with a choice of using Google Fonts (saves you bandwidth and can save the user bandwdith and page load times since it's cached between sites) and just accepting that Google Chrome Windows users will have an inferior experience or self-hosting your fonts (you do the bandwidth, increased page load to users, making sure you get the font loads in the correct order, slightly longer load time for Safari users). It's kind of amazing that this is still unfixed given how poorly the font rendering makes pages look and the fact that every other Windows browser handles it with aplomb.
I have had that issue starred for years, as I assume most of the others have. The failure of Chromium to support DirectWrite in a reasonable timeframe has kept me pure in my unwavering support of Firefox, even when Chrome was considered the hipper browser. It's easier now to remain with Mozilla, what with anti-Google sentiment becoming mainstream.
Jokes aside, it's embarrassing how long that issue has been left to rot. All fonts in Chrome-Windows look awful once one is used to Firefox or Internet Explorer's rendering.
Does this mean it'll have the same terrible antialiased text rendering IE has? That only looks good on high DPI? That's one of the main reasons I've been on Chrome: no blurry text.
This is most relevant on Retina/hi-dpi displays, that's where DirectWrite shines and Chrome flails. For regular-dpi displays, I think DirectWrite is actually a bit worse than the traditional Win font rendering.
I don't think this is related to the issue this article talks about, but it may be relevant to Windows Chrome users whose fonts suddenly look bad...
I noticed in the past week that sites of mine that had imported a font from Google Web Fonts without explicitly specifying to import bold/italics versions too were looking odd (e.g. weird text-shadow for no reason on what used to appear bold). In past versions of Chrome (or perhaps it's Google Web Fonts that has changed, I'm not sure), I've been able to use [b] and [i] HTML tags around text and my Google fonts have responded accordingly (without my needing to explicitly import bold/italic versions) -- but that's no longer the case. The fix is (obviously) to explicitly import the versions of the fonts you bold/italicize, but it actually took me a little while to figure out that that (and not some weird CSS issue) was the problem.
Hopefully this saves a few other people 15 minutes of poring over their CSS trying in vain to figure out what isn't working!
Just MAKE SURE NOT TO COPY FROM THE FONTSPRING POST linked to in the article. Their code samples have curly-quotes in the CSS which fails silently and you will go nuts trying to debug it. Um, hypothetically. Ahem.
All browsers: why can't you display an intermediate font while downloading the custom font-faces?
It just sucks so badly. Most time I'm stuck on a 8 KByte/sec cellphone connection, and I have to wait YEARS just to read text - or press ESC to force display of system fonts.
You might think this is just "they didn't bother implementing that", but in fact some people considered this a feature and browsers added "flash of invisible text" as a feature.
Browsers are in a tough spot: when you specify a font, there's no way to programmatically determine how critical that font is to your design (see the FOUT discussion saurik linked above).
There are two things which we need to fix this:
1. Simple, robust font load events so you could treat this like any other type of content and make the decision about whether to display an alternative until something finishes loading:
2. As a lower priority, browser support for using the @font-face unicode-range property to avoid unnecessary downloads. It's not uncommon for sites to use a webfont with known support for non-ASCII characters to avoid issues with older operating systems & browsers. Unfortunately, there's a huge problem with this because specifying a webfont will cause it to be downloaded at least as soon as an element on the page uses that font[1] and it'd be really nice if there was a way to e.g. list a font which should only be downloaded if one of the earlier fonts in the stack doesn't contain the needed glyph so I could say "font-family: Arial, noto-sans" and have a Windows 7 user not download anything while still displaying correctly, if slower, for an XP user.
I thought specifying a fallback font does that. Of course, problem is that many websites try to avoid the dreaded FOUT, and end up hiding text, or even the whole site, until fonts are loaded.
For those of you who don't care about custom fonts, I made a quick extension[0] that disables use of all web-fonts (woff/ttf/otf) by blocking all requests made to these extensions. It does save me a lot of bandwidth when I do enable it. Plus, it saves you from FOUT. Its open source on GitHub as well[1].
I still have to add support for a whitelist, so that it can be actually useful (for instance, GitHub needs web-fonts for most of its interface).
What's "a lot"? Aren't font loads on the order of a few kilobytes a page? Seems like loading the front page of the New York Times once would use more bandwidth than all the web fonts you run into for a month.
I found using the SVG version rather then tff helps a bit on windows. Its nasty looking but it does make it a bit more presentable. Only thing is that for some reason Google Web Font doesn't display the SVG so I have to use something like Font Squirrel to create my fonts and host locally. I only tend to do this if the client just so happens to tests on windows , most of the time they don't care since they are on macs so its not that much of an hassle when I have to go down this road.
Edit: Maybe I should of read the article before my comment, seems he does the same thing.
Its almost fixed, but then it needs to go through the "food chain" before it reaches every one of us. So, only in about 6 months that it might be finally fixed.
[+] [-] JohnTHaller|12 years ago|reply
[+] [-] giovannibajo1|12 years ago|reply
[+] [-] Tomdarkness|12 years ago|reply
See the issue here:
https://code.google.com/p/chromium/issues/detail?id=25541
For details on how to enable DirectWrite in Chrome Canary. Might be worthwhile to see what your fonts look like using DirectWrite.
[+] [-] bhauer|12 years ago|reply
Jokes aside, it's embarrassing how long that issue has been left to rot. All fonts in Chrome-Windows look awful once one is used to Firefox or Internet Explorer's rendering.
[+] [-] JohnTHaller|12 years ago|reply
[+] [-] MichaelGG|12 years ago|reply
Does this mean it'll have the same terrible antialiased text rendering IE has? That only looks good on high DPI? That's one of the main reasons I've been on Chrome: no blurry text.
[+] [-] mwsherman|12 years ago|reply
[+] [-] ahugon|12 years ago|reply
I noticed in the past week that sites of mine that had imported a font from Google Web Fonts without explicitly specifying to import bold/italics versions too were looking odd (e.g. weird text-shadow for no reason on what used to appear bold). In past versions of Chrome (or perhaps it's Google Web Fonts that has changed, I'm not sure), I've been able to use [b] and [i] HTML tags around text and my Google fonts have responded accordingly (without my needing to explicitly import bold/italic versions) -- but that's no longer the case. The fix is (obviously) to explicitly import the versions of the fonts you bold/italicize, but it actually took me a little while to figure out that that (and not some weird CSS issue) was the problem.
Hopefully this saves a few other people 15 minutes of poring over their CSS trying in vain to figure out what isn't working!
[+] [-] xcrunner529|12 years ago|reply
[+] [-] badman_ting|12 years ago|reply
Developers, man.
[+] [-] JustResign|12 years ago|reply
<.< Double-checking my CSS in the article >.>
[+] [-] mschuster91|12 years ago|reply
It just sucks so badly. Most time I'm stuck on a 8 KByte/sec cellphone connection, and I have to wait YEARS just to read text - or press ESC to force display of system fonts.
[+] [-] saurik|12 years ago|reply
http://www.paulirish.com/2009/fighting-the-font-face-fout/
(There are also some interesting ramifications to these various techniques for the various "icon fonts" that seem to be all the rage these days.)
http://filamentgroup.com/lab/bulletproof_icon_fonts/
[+] [-] acdha|12 years ago|reply
There are two things which we need to fix this:
1. Simple, robust font load events so you could treat this like any other type of content and make the decision about whether to display an alternative until something finishes loading:
http://dev.w3.org/csswg/css-font-load-events/
2. As a lower priority, browser support for using the @font-face unicode-range property to avoid unnecessary downloads. It's not uncommon for sites to use a webfont with known support for non-ASCII characters to avoid issues with older operating systems & browsers. Unfortunately, there's a huge problem with this because specifying a webfont will cause it to be downloaded at least as soon as an element on the page uses that font[1] and it'd be really nice if there was a way to e.g. list a font which should only be downloaded if one of the earlier fonts in the stack doesn't contain the needed glyph so I could say "font-family: Arial, noto-sans" and have a Windows 7 user not download anything while still displaying correctly, if slower, for an XP user.
1. Test cases & bug reports here: http://chris.improbable.org/experiments/browser/webfonts/uni...
[+] [-] ferongr|12 years ago|reply
Obligatory "Firefox doesn't suffer from this". It will display the default sans-serif system font while the website's font load.
[+] [-] sergiotapia|12 years ago|reply
I just use:
[+] [-] gizmo|12 years ago|reply
[+] [-] ehsanu1|12 years ago|reply
[+] [-] lampe3|12 years ago|reply
I think chrome beta on android does that but iam not sure right now
[+] [-] kybernetikos|12 years ago|reply
[+] [-] captn3m0|12 years ago|reply
I still have to add support for a whitelist, so that it can be actually useful (for instance, GitHub needs web-fonts for most of its interface).
[0]: https://chrome.google.com/webstore/detail/disable-web-fonts/...
[1]: https://github.com/captn3m0/disable-web-fonts
[+] [-] devindotcom|12 years ago|reply
[+] [-] kclay|12 years ago|reply
Edit: Maybe I should of read the article before my comment, seems he does the same thing.
[+] [-] adventured|12 years ago|reply
I use this to fix it:
-webkit-text-stroke-width: 0.15px; (some suggest 0.25px)
[+] [-] tdj|12 years ago|reply
Also, the same problem is also present in Safari for Windows, in case anyone actually uses it..
[+] [-] joaohenriques|12 years ago|reply
Its almost fixed, but then it needs to go through the "food chain" before it reaches every one of us. So, only in about 6 months that it might be finally fixed.
[+] [-] mistercow|12 years ago|reply
While that would work, I wonder if copying and modifying their CSS would technically be a TOS violation.
[+] [-] ciquar|12 years ago|reply
http://www.dev-metal.com/fix-ugly-font-rendering-google-chro...
[+] [-] asadotzler|12 years ago|reply
[+] [-] joseph_cooney|12 years ago|reply
[+] [-] omegote|12 years ago|reply