Windows Chrome, why do my fonts look so bad?(lee.greens.io)
lee.greens.io
Windows Chrome, why do my fonts look so bad?
http://lee.greens.io/blog/2014/01/13/windows-chrome/
56 comments
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.
While the bug is being fixed, why doesn't Google add the SVG workaround to the CSS being served for its fonts?
I have no idea. We've been suggesting that for years as well. But the web fonts team seems to have no interest in mitigating the Google Chrome Windows bug.
"ChromeOS" Chromebooks look so much nicer than Windows... if you want to browse the web like it's supposed to work, get a Chromebook. /sarcasm
Seriously, this has bugged me for a very long time myself. I don't get why it hasn't been fixed, it's been an issue as long as I can remember, and fortunately, other than at work or my desktop at home, I'm not on windows... My HTPC, which I use for reading more than anything is on Ubuntu, and I recently got a Chromebook as an interim replacement for my stolen MBP.
Though some of the comments mention (rightly) that SVG fonts are larger files than WOFF... they don't seem to take into consideration that SVG, being text/xml can be greatly compressed in transit. I also, REALLY don't get why Google's web fonts' css doesn't give the SVG first to chrome+windows users, so things at least look better there until they fix chrome.
Seriously, this has bugged me for a very long time myself. I don't get why it hasn't been fixed, it's been an issue as long as I can remember, and fortunately, other than at work or my desktop at home, I'm not on windows... My HTPC, which I use for reading more than anything is on Ubuntu, and I recently got a Chromebook as an interim replacement for my stolen MBP.
Though some of the comments mention (rightly) that SVG fonts are larger files than WOFF... they don't seem to take into consideration that SVG, being text/xml can be greatly compressed in transit. I also, REALLY don't get why Google's web fonts' css doesn't give the SVG first to chrome+windows users, so things at least look better there until they fix chrome.
It doesn't bug me much other than having to self-host font files and ensure they're in the hacky order to fix Chrome's issue. Then again, I don't use Chrome other than for testing web pages. I run Firefox on Windows and Android and sync them. When Firefox first started using DirectDraw, there were some issues with fonts, but Mozilla made it a priority and got it sorted relatively quickly (lightning fast compared to Chrome's font bugs).
Couldn't they also only serve up the fix to affected chrome browsers by checking the user agent string in the request header? That way they give the most effective format based on the browser and os requesting it.
That's what I meant. The Google Fonts CSS is already based on the user agent string (it doesn't contain media-queries or similar tricks), so they just need to treat Chrome+Win differently and tell it to load the SVG version.
Chrome Canary has experimental support for DirectWrite which should make your fonts, and text in general look much nicer.
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.
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.
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.
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.
Similar type of deal with [going 64-bit](https://code.google.com/p/chromium/issues/detail?id=18323) on Mac OS X. Has languished for multiple years. DirectWrite shipped in 2009, one month after Snow Leopard with 64-bit recommended for apps by default.
Plus ASLR is much less effective with only a 32 bit address space. (Firefox on OS X is a 64 bit application.)
Not even when you're not used to the other browsers' font rendering. On some of Google's web pages the fonts are actually unreadable unless you scale the page to 250% or so.
>>>> All fonts in Chrome-Windows look awful once one is used to Firefox or Internet Explorer's rendering.
Kind of hard to imagine IE actually renders something better than Chrome. I thought that would be enough to get them motivated to get this corrected. Guess I was wrong.
Kind of hard to imagine IE actually renders something better than Chrome. I thought that would be enough to get them motivated to get this corrected. Guess I was wrong.
IE11 is a really good browser. Fast and rendering is flawless
Note that the discussion begins over 4 years ago. Still can't believe it's been this long.
>text in general look much nicer
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.
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.
Not sure I agree..while it will depend on your display, I certainly find the left in this image (DW) easier to read than the right (GDI)
http://i4.minus.com/igp9IxeEX51ES.png
(I know these comparisons have been done to death in the past)
http://i4.minus.com/igp9IxeEX51ES.png
(I know these comparisons have been done to death in the past)
I'm not disagreeing with you, but I noticed this on a garden-variety 24" 1920x1200 LCD, Windows 7.
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!
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!
It's a bug and really annoying.http://code.google.com/p/chromium/issues/detail?id=332958
Thank you (and ahugon) for confirming this! I noticed one of our sites was having this issue and wasn't sure what was causing it.
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.
Developers, man.
Developers, man.
Thanks.
<.< Double-checking my CSS in the article >.>
<.< Double-checking my CSS in the article >.>
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.
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.
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/
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/
That would require site code changes and does not help me, the victim of a severe lack of testing...
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:
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...
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...
Just want to point out one minor nit to pick.. NEVER specify "Arial" or "Helvetica" as fonts and simply fall back to `sans-serif` On OSX you'll get Helvetica, on Windows you'll get Arial, which display better on their given platforms.. a Helvetica-like font is the default on pretty much every given platform for web browsers.
I would say, that if a fallback font is specified in the font-face rule, then that should be used while the web-font is downloaded.
Also, it would be nice, as you say, if a fallback would be used when a glyph isn't in the specified font (only for that glyph).
I would say, that if a fallback font is specified in the font-face rule, then that should be used while the web-font is downloaded.
Also, it would be nice, as you say, if a fallback would be used when a glyph isn't in the specified font (only for that glyph).
You're generally right about `sans-serif` vs. Arial/Helvetica. There used to be a complication in that even on OS X, Arial has significantly more glyphs than Helvetica but as browsers get better font substitution support and stop breaking ligatures (http://chris.improbable.org/experiments/browser/combining-ha...) this matters less.
It would, of course, also be significantly less important if they optimized the download decision so you could use something like noto for everything and not have to worry about significant visual differences.
It would, of course, also be significantly less important if they optimized the download decision so you could use something like noto for everything and not have to worry about significant visual differences.
I have just given up on using Google Webfonts. :)
I just use:
I just use:
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;Why not just:
font-family: sans-serif;
I've read that Windows' Helvetica font is uglier than Arial (perhaps a hinting issue) and, since few Windows'users have Helvetica Neue, that a recommended don't family is thus:
font-family: "Helvetica Neue", Arial, sans-serif;Unless the situation has changed, the Windows registry has an entry to show Arial when Helvetica is requested.
Recent versions of Internet Explorer use placeholder fonts by default.
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.
The latter are the worst of the bunch. Same goes for those fucktards who make their site load (i.e. remove the display:none on the content) on loading/error event (timeout etc) of the social media plugins. Oh, and of course no images and no nothing has been loaded... so ANOTHER time pressing ESC and hope that I finally will get some text.
Please, developers out there: test your websites on REAL mobile devices WITHOUT LTE/3G/UMTS. You WILL be surprised how fucking awful your site is on a low-bandwidth link.
(end of rant)
Please, developers out there: test your websites on REAL mobile devices WITHOUT LTE/3G/UMTS. You WILL be surprised how fucking awful your site is on a low-bandwidth link.
(end of rant)
In 2014, targeting mainly Western users, what am I using as a "real connection"?
In Australia, even UMTS can drop below 1 megabit on some carriers.
In Australia, even UMTS can drop below 1 megabit on some carriers.
I'm not even sure I know where to get a "real" mobile device or connection.
If in doubt, use "tc" to do traffic shaping (on Linux) or SeriousBit's NetBalancer (on Windows). http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-...
I regularly test my websites with various tc settings, including traffic shaping, packet loss, line outages etc. Lots of manual work, but it really helps to see which parts of your API can be traffic-optimized.
I regularly test my websites with various tc settings, including traffic shaping, packet loss, line outages etc. Lots of manual work, but it really helps to see which parts of your API can be traffic-optimized.
Try Safari in the Simulator while using Network Link Conditioner. Really slick.
One solution for your problem could be that the Browser displays the font in the system font and when the costume font is loaded it can change to it.
I think chrome beta on android does that but iam not sure right now
I think chrome beta on android does that but iam not sure right now
Actually, they can, the only issue is that most web developers take deliberate measures to avoid 'Flash Of Unstyled Content'.
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).
[0]: https://chrome.google.com/webstore/detail/disable-web-fonts/...
[1]: https://github.com/captn3m0/disable-web-fonts
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
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.
Edit: Maybe I should of read the article before my comment, seems he does the same thing.
I've noticed as well that Windows Chrome produces a bit of an ugly jagged look to even common fonts.
I use this to fix it:
-webkit-text-stroke-width: 0.15px; (some suggest 0.25px)
I use this to fix it:
-webkit-text-stroke-width: 0.15px; (some suggest 0.25px)
This. I use 0.1px for smaller type, and 0.25 for bigger. It also makes it look thicker.
Also, the same problem is also present in Safari for Windows, in case anyone actually uses it..
Also, the same problem is also present in Safari for Windows, in case anyone actually uses it..
Take a look at comment #123 on https://code.google.com/p/chromium/issues/detail?id=137692#c...
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.
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.
So the article is suggesting that you could do this with Google Web Fonts by copying the CSS instead of linking to it, and then changing the order.
While that would work, I wonder if copying and modifying their CSS would technically be a TOS violation.
While that would work, I wonder if copying and modifying their CSS would technically be a TOS violation.
This is, for the most part, a rehash of this article:
http://www.dev-metal.com/fix-ugly-font-rendering-google-chro...
http://www.dev-metal.com/fix-ugly-font-rendering-google-chro...
I presume this is simply that Chrome uses GDI rather than DirectWrite here. Perhaps they're prioritizing speed over beauty?
And also the ability to run on Windows XP, where DirectWrite doesn't exist.
This has been a bug for so long, it feels like Groundhog day. Chrome developers couldn't care less about windows users.