Why fonts look awful in Chrome, and how to fix it(tanookisuitlabs.com)
tanookisuitlabs.com
Why fonts look awful in Chrome, and how to fix it
http://tanookisuitlabs.com/your-fonts-look-bad-in-chrome-heres-the-fix/
16 comments
Hey Paul... whenever certain CSS3 transition/animations run, custom fonts (typekit or google fonts... maybe others) will switch from the default subpixel aa to -webkit-font-smoothing: antialiased style aa for the duration, then switch back. From that second link, it's probably an OS X specific bug.
I could have sworn http://www.usabilitypost.com/2012/11/05/stop-fixing-font-smo... was just recently linked here.
Read it. Tanooki is wrong.
Read it. Tanooki is wrong.
I link to that article in the post, and disagree with their conclusion, but provide lots of examples for everyone to make their own judgement.
In short, my 3 arguments are that: "antialiased" is most consistent with the display in other browsers, subpixel antialiasing looks terrible on light fonts on dark backgrounds, and it's impossible to match certain thin font weights from photoshop designs while subpixel-antialiasing is on.
In short, my 3 arguments are that: "antialiased" is most consistent with the display in other browsers, subpixel antialiasing looks terrible on light fonts on dark backgrounds, and it's impossible to match certain thin font weights from photoshop designs while subpixel-antialiasing is on.
You make a claim that this is specifically for Chrome on OS X, yet I don't think you've done enough homework to make such a broad statement. I am using Chrome 23.0.1271.101 on OS X 10.8 no a retina MBP, and fonts looks beautiful across the board (with no mods on my part). All those in your post look the same to me. What gives?
I first clicked on the article hoping to get an answer for the crappier font rendering in Chrome on Win32. Font rendering is one thing IE still does better than Chrome/WebKit.
I first clicked on the article hoping to get an answer for the crappier font rendering in Chrome on Win32. Font rendering is one thing IE still does better than Chrome/WebKit.
Chromium Version 20.0.1132.47 Ubuntu 12.04 (144678)
You should say "other operating systems" maybe, not "other browsers". On OS X, Firefox, Safari, and Chrome all defer to the system as to whether to default to subpixel antialiasing. I wouldn't be surprised if Windows 8's metro version of IE did the same. And Firefox ignores -webkit-font-smoothing:antialiased, so you still can't claim consistency.
And if you're trying to be pixel perfect to Photoshop, why aren't you using PNG? Anything else isn't going to work, after all.
But if you're only arguing for white on black, well I guess. But you don't point this out, and white on black is horrid for text anyway.
And if you're trying to be pixel perfect to Photoshop, why aren't you using PNG? Anything else isn't going to work, after all.
But if you're only arguing for white on black, well I guess. But you don't point this out, and white on black is horrid for text anyway.
On Windows, Firefox and Chrome render all columns identically. I think they're pixel-perfect replicas. http://i.imgur.com/9iaZq.png
No they are not, at least not in the image you linked. Check for example, space between a and z in Londrina's Lazy.
[deleted]
Hey Eric, I'm the author of the linked post. I actually do mention that light fonts on dark backgrounds look terrible on OS X and suggest using the antialiasing mode as a fix. Dark text on a light background is another story however.
> it's impossible to match certain thin font weights from photoshop designs
Why do you care how your users are choosing to view your text?
Why do you care how your users are choosing to view your text?
Are the two columns supposed to look similar? Because on Safari in OS X, the right one is very bold, and the left one is often way too spindly, especially on the last font. I wouldn't reliably call one column or the other better, but they are definitely very different.
You can get this effect everywhere by turning off LCD font smoothing in System Preferences > General. Personally, I don't like the color fringing of subpixel rendering so I keep it turned off. Most apps require restarting before they will notice that you've toggled the LCD smoothing checkbox, but Xcode will immediately redraw itself, making it easy to see the difference.
I'm pretty sensitive to the artifacts introduced via smoothing, though some don't notice it at all. It was so bad and so weird in so many ways on so many sites that I turned it off altogether for a time. I preferred to break layouts and circumvent the designers' intent rather than look at those hairy little beasts they called letters.
Luckily, this is one of the few things that high-resolution screens truly do fix and the main reason I bought an iPad 3. When smoothing is done on a level where you can perceive the pixels, it's crude and, for me, ineffective. But when you pass the ~200ppi mark, it starts actually fading into curves and marks rather than polychromatic halos. I'm thankful for this, but wish I could get a desktop OS and monitor that really excelled in text display. For now, every time I want to read something long on the net, I absolutely have to send it to my iPad. As far as inconveniences go it's pretty minor, but we can do better.
Luckily, this is one of the few things that high-resolution screens truly do fix and the main reason I bought an iPad 3. When smoothing is done on a level where you can perceive the pixels, it's crude and, for me, ineffective. But when you pass the ~200ppi mark, it starts actually fading into curves and marks rather than polychromatic halos. I'm thankful for this, but wish I could get a desktop OS and monitor that really excelled in text display. For now, every time I want to read something long on the net, I absolutely have to send it to my iPad. As far as inconveniences go it's pretty minor, but we can do better.
Seriously. I can't wait until we have high DPI screens everywhere.
Using Chrome on the MBP retina, I can assure you that there is nothing to fix. Everything is crisp and clear.
The effect is certainly lessened on the retina displays, but we tested it and certainly saw a difference. Just for fun, add -webkit-font-smoothing:antialiased; to the html element of random sites and see what you think with it on and off.
Is ugly article header is an attempt at proving a point?
http://content.screencast.com/users/Markizko/folders/Jing/me...
http://content.screencast.com/users/Markizko/folders/Jing/me...
I've been using this CSS code to 'fix' light text on dark backgrounds. However, it's not wise to apply it to dark text on light backgrounds. It often makes the letters too thin and hard to read on standard resolution displays.
[deleted]
People are saying they can't see the difference. So here's some screen shots taken from Google Chrome (Version 23.0.1271.101) on Mac OS X Snow Leopard on a 2009(?) 13" MacBook Pro.
(http://imgur.com/XDgGC)
I prefer light on dark, but hate white on black. All of these are uncomfortable to read for me.
(http://imgur.com/XDgGC)
I prefer light on dark, but hate white on black. All of these are uncomfortable to read for me.
I thought this was going to fix the big difference I see between Chrome and IE10 on Win8 desktop:
http://i.imgur.com/e2Dwi.png
Guess not :( Any ideas?
http://i.imgur.com/e2Dwi.png
Guess not :( Any ideas?
Which side needs fixing? IE looks better for headlines (lots of pixels to play with) but with normal type it is far worse. This all started around mid-2000s when the WPF team decided subpixel accuracy was more important than clarity, and it's spread to other teams since. Chrome's decent font rendering, using ClearType like the OS specifies, is one of the reasons I still use it and can't stand IE.
Maybe if high-DPI mode worked and laptops had high res screens it'd be better, but that's not the case for a while.
Maybe if high-DPI mode worked and laptops had high res screens it'd be better, but that's not the case for a while.
I thought the same. I've been mostly using Linux for the past month and now that I switched back to Windows (trying out windows 8) this is something that is really bugging me.
And it's not just the font aliasing. Some UTF-8 characters are not even rendered (only squares appear). There was one article I saw here (I think it was about lambda calculus) that I had to read on IE.
Maybe its time to go back to firefox on windows.
And it's not just the font aliasing. Some UTF-8 characters are not even rendered (only squares appear). There was one article I saw here (I think it was about lambda calculus) that I had to read on IE.
Maybe its time to go back to firefox on windows.
Why is this only showing up on OSX? Is it a bug with Chrome's webkit?
I've been scratching my head about this bug for a while now, and now I know how to fix it. Here's some screenshots of what this fix has done for a site I'm working on:
http://imgur.com/a/W6dtC
I'm using the 'Sketch Block' font, and in Chrome 23.0.1271.101 on OSX it looks awful - but this fixed it.
I like 'em thick 'n curvy.
To paraphrase the article...
No offence but you don't know jack about fonts ; )
I mean: zooming in on a subpixel antialiased fonts and showing us the magnified to try to 'make a point' !? I hope you do realize that the subpixel anti-aliasing trick is totally gone once you zoom in right?
You do realize this right?
If so, why do you even show that in your article?
I find a bit strange that basically every single example at normal size he uses give better result for the column he names "fat & fuzzy".
And that's with Chrome on an old MacBook.
Interesting his colum named 'Thin & Pretty' doesn't look like white text on black background but 'uneven gray text on black background'.
Freackingly ugly to read. The colum he considers 'fat' and 'fuzzy' actually looks much better.
And I've typeset books using Quark XPress so I'm not 'seeing things' here: I know a thing or two about fonts ; )
No offence but you don't know jack about fonts ; )
I mean: zooming in on a subpixel antialiased fonts and showing us the magnified to try to 'make a point' !? I hope you do realize that the subpixel anti-aliasing trick is totally gone once you zoom in right?
You do realize this right?
If so, why do you even show that in your article?
I find a bit strange that basically every single example at normal size he uses give better result for the column he names "fat & fuzzy".
And that's with Chrome on an old MacBook.
Interesting his colum named 'Thin & Pretty' doesn't look like white text on black background but 'uneven gray text on black background'.
Freackingly ugly to read. The colum he considers 'fat' and 'fuzzy' actually looks much better.
And I've typeset books using Quark XPress so I'm not 'seeing things' here: I know a thing or two about fonts ; )
Anyone have screenshots? I don't have OS X installed anywhere right now.
I see no such thing, nor a difference. On Chrome OSX Version 23.0.1271.101
Did you check the comparisons in the article? If they truly don't look different, I'd love to see a screenshot of the article so I can check it out and dig into it. Thanks!
he may be on a retina mac, i see no difference on chrome either
https://dl.dropbox.com/u/1437645/chrometext.png
https://dl.dropbox.com/u/1437645/chrometext.png
Look at the Londrina. The right one is a little bit bolder.
Even so, I don't think I would ever notice something like that if it wasn't for the side-by-side comparison.
Even so, I don't think I would ever notice something like that if it wasn't for the side-by-side comparison.
Nah, I just opened it in Gimp, moved the right one on top of the left and toggled it visible/invisible. It's identical (at least from the screenshot posted by the GP.
None here either. 23.0.1271.101 on 10.6.8
http://i.imgur.com/LFPrb.png
23.0.1271.101, 10.8.2 non-retina
23.0.1271.101, 10.8.2 non-retina
The short version: http://lists.w3.org/Archives/Public/www-style/2012Oct/0014.h... The long version: https://code.google.com/p/chromium/issues/detail?id=152304
In addition: text rendering is very specific to the combination of browser & rendering layer. Targeting Mac Chrome with a webkit-wide property is a good way to get inconsistent results across your various desktop webkits and mobile webkits.