New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 152304 link

Starred by 186 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

"-webkit-font-smoothing: antialiased" stopped working in 22.0.1229.79

Reported by jcpar...@gmail.com, Sep 25 2012

Issue description

Chrome Version       : 22.0.1229.79
OS Version: OS X 10.7.4
URLs (if applicable) : https://my.mobilisafe.com/
Other browsers tested:
     Chrome 21.0.1180.89: OK
     Safari 6.0 (7536.25): OK

What steps will reproduce the problem?
Load the website above.

What is the expected result?
Skinny text (before picture)

What happens instead?
Chunky text (after picture)


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4


 
after - chunky text.png
21.3 KB View Download
before - skinny text.png
23.5 KB View Download
Showing comments 49 - 148 of 148 Older

Comment 49 by jtsut...@gmail.com, Sep 27 2012

@Comment 46

That is the same as #2. Users/Designers aren't going to care who is at fault, they are going to blame Chromium when it has the worst looking font rendering of all browsers.

Furthermore, Apple *shouldn't* change the font rendering if it will affect all native apps. Nobody is upset about font rendering with them.

The world isn't perfect and Chromium is backed into a shitty place here.  Sometimes the doing things correctly is doing things worse.

Comment 50 by Deleted ...@, Sep 27 2012

Comment 39 by bunge... "The only real argument so far for it is that web developers don't like glyph rendering on OSX"

To be honest, the only place I've noticed these issues with glyph rendering on OSX is on webkit browsers, in particular Chrome. All other native apps, etc render just fine. That's why I consider it to be a webkit issue, not an OSX / Apple issue. 
I too have a had over a year's worth of work flushed down the drain in the last 24 hours.  And we've been telling our users Chrome is the browser of choice.  But now I am embarrassed to show our site in Chrome.

Comment 52 by Deleted ...@, Sep 27 2012

This really is sad. Chrome dudes.. were you guys were unaware of the massive degree that the web relies on font-smoothing? if not, why did you push this new bowser update without some sort of alternate method to control the font's weighted appearance? As mentioned in @comment 48.

I build a widely used web font called Pictos: http://pictos.cc
I also have a font service for web fonts (much like TypeKit). By providing no alternate method of making the fonts look better than default rendering, you have really hosed any and all web designers/developers who use web-fonts. Which is most everyone. Please re-read that last sentence.

When people were told to stop using text-stroke years back, the font-smoothing alternative was immediately adopted by designers & developers around the globe. We have been finding ways to improve default rendering for years and years. Please provide us with a new way ASAP. If you can't, please direct us to the place we can, or maybe setup some thread with Apple that we can all contribute our voice to.

You have the voice, please use it to fix this issue ASAP.

Thanks for making webkit the worlds dominant browser :)

@Comment 43 by vin..:
>Even if I'm not a big fan of Apple (the company), this is why I love their products (e.g. Safari). They do care about designers.

This gave me a small chuckle and a bit of bewilderment. Most here are railing about how terrible CoreGraphics draws lcd smoothed glyphs and how not having a way to override the user's settings and make things look the way they do on other platforms is the end of the web. (Ok, so that might be a bit of hyperbole.) On the other hand, there is this general sense of fondness toward Apple.

To some degree I can understand this, historically Apple has taken the more technically correct route towards glyph rasterization. However, having the platform's public font api always dilate the outlines of glyphs by a constant percentage when doing lcd smoothing is a strange way to care about designers. That Safari happens to have an undocumented feature which can be used for an off-label workaround also seems less than being entirely supportive.

If you remain convinced Apple wants to do right by visual designers in general, ask them to fix it, see Comment 46. While Chrome may or may not end up providing some specific work-around, Apple could fix this for everyone on OSX.
This is embarrassing... I have four websites that rely heavily on "-webkit-font-smoothing: antialiased" and all look absolutely terrible in chrome at the moment. Please revert :(
I'm dealing with the same issue. Fonts look horrible on Disqus.com

Should look like: http://cl.ly/image/2S0x3T152Z3o
Currently looks like: http://cl.ly/image/1a0T2W3H3Y2u

Comment 56 Deleted

bungeman, I respect your approach and agree, this is inherently an OS X CoreGraphics issue.

Taking all negative comments from some of the commenters on here with a grain of salt, what is the next step that we as web developers and designers should be doing now to our website CSS files make our fonts look the way we expected them to look in Chrome now? (oh and with the fastest possible turn around time)

Is contacting Apple even an option for "fast turnaround"? (if that even exists) 

Comment 58 by Deleted ...@, Sep 27 2012

@Comment 57: "bungeman, I respect your approach and agree, this is inherently an OS X CoreGraphics issue."

Where other than Chrome and Safari have you ever run into these font rendering issues? I certainly haven't noticed it anywhere else. If it's a predominantly webkit based issue, shouldn't the onus be on the browser developers to provide a fix? 
@Comment 44 by a...:
>again we have tested this and this is NOT the case.

Actually, it does. Disable lcd smoothing with 'defaults -currentHost write -globalDomain AppleFontSmoothing -int 0' or uncheck 'Use LCD font smoothing when available' in the Appearance settings of the System Preferences. Then restart Chrome. The user's system settings are respected, and everything is regular anti-aliased and has the weight one would expect.

>But Chrome V22 no-lcd-smoothing DOES NOT match Native no-lcd-smoothing

True, Chrome V22's regular anti-alias when the user's settings are lcd-smoothing does not match native no-lcd-smoothing. In an ideal world, the user's setting of lcd-smoothing could always be respected completely and Chrome would never fall back to regular anti-alias. Sometimes, because of current limitations, Chrome cannot do so and instead uses the closest possible rendering.

It seems you are arguing that what you want is native no-lcd-smoothing. However it appears that what you really want is to force rasterization from unmodified outlines (as would be beneficial to an icon font). However, native no-lcd-smoothing is no guarantee of this, which is why I was proposing a 'CSS Glyph Rasterizer', but see the last part of Comment 39.
@comment 53: I'd like to give a reward to bunge for his highly communication skills. Instead of coming up and smoothing up the atmosphere, he's making everybody feel more irritated by this issue. Do not look more, it is apple's fault, chromuim is right and you are a bunch of ignorant and stupid people just by the fact of using a non standar and recomended call such as font-smoothing....

Now looking at the real facts:

I have many websites that look amazingly bad right now under chrome OSX (behing for some of my sites the mosts used os and browser in the amount of visits). When the user will arrive to the site he will for sure not send me a mail (or to apple) complaining about the fonts looking bad. He'll just feel, after a while navigating, that something is wrong in here. And he'll simply never come back and I'll loose the purpose of my everyday job :)

Right now I am waiting a couple of more days if this issue will be corrected. if not I have not other choice than coming back to the photoshop part, retouch my designs to avoid at all cost using bold types and go through thousands of lines of css. Also start avoiding using @font-face types in the future, since they will surely not be optimized for any native OS... Back to Arial! :)


Comment 61 by psol...@gmail.com, Sep 27 2012

Dear Chromium developers,

I (and EVERYONE else) don't care if the font rendering bug is the fault of Apple, global warming or russian mafia. Safari works fine, so swallow your pride and make it work in Google Chrome too! Or otherwise you just admit that it's ok that your browser suck! Should we stop using your browser?
> True, Chrome V22's regular anti-alias when the user's settings are lcd-smoothing does not match native no-lcd-smoothing. 

I believe that this is the root of the entirety of this issue. 

To be entirely clear when you say "Chrome V22's regular anti-alias" you mean the same as "Chrome V22's NO-LCD-smoothing", correct?   I think the variety of terms can be confusing especially to anyone who is trying to catch up on the situation after the fact. Subpixel-AA = LCD Smoothing.  Regular AA = "Antialiased" = NO-LCD-Smoothing. 

The situation is, more plainly:

* If an OSX user disables "Use LCD font smoothing" in their system preferences (or via the CLI) then they will not see shapes (letters or icons) overly-bolded and blurry in Chrome, Safari, or Native apps

* If the author of a OSX native app disables "LCD font smoothing" for text within their app then the users of the app  will not see shapes (letters or icons) overly-bolded and blurry in that app.

* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling LCD smoothing) on text within a web page, their visitors using OSX and Safari WILL NOT see shapes (letters or icons) overly-bolded and blurry on that page

* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling of LCD smoothing) on text within a web page, their visitors using OSX and Chrome V21 WILL NOT see shapes (letters or icons) overly-bolded and blurry on that page

HOWEVER...

* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling of LCD smoothing) on text within a web page, their visitors using OSX and Chrome V22 WILL see shapes (letters or icons) overly-bolded and blurry on that page

Can we agree that the above statements are true?

> In an ideal world, the user's setting of lcd-smoothing could always be respected completely and Chrome would never fall back to regular anti-alias. Sometimes, because of current limitations, Chrome cannot do so and instead uses the closest possible rendering.

This is a convoluted and confusing point.  You seem to be referring to a situation that has not even been referenced where Chrome automatically flips over to NO-LCD-smoothing because it can't do LCD-smoothing for some reason, even though the dev has NOT specified "-webkit-font-smoothing:antialiased" and the user has NOT disabled LCD-smoothing on their end.  I don't even see how this is relevant, and I don't think anyone is complaining about this!

> It seems you are arguing that what you want is native no-lcd-smoothing. However it appears that what you really want is to force rasterization from unmodified outlines (as would be beneficial to an icon font). 

No not at all, I would like '-webkit-font-smoothing:antialiased' to render shapes the same way that disabling system LCD-smoothing and restarting chrome does, AKA the same way that disabling LCD-smoothing in a native app does. OR of course, the availability of any new css property or combination of properties that allows us to achieve rendering in this way.
With all due respect to the Chrome development team for creating what is in my opinion the best browser in the world. I feel like things are taking a turn for the worse here. I was surprised to see our consumer-facing website being defaced last morning. These events have triggered 2 questions:

1. How could a 'fix' with such a massive impact like this have been pushed to the stable branch without adequate warning? It seems to me; that said developer should have foreseen that this would visually 'break' many websites, and instead phase in the change in over a course of 2-3 months.

2. What is your definition of correctness in development? It certainly appears caring for customers does not belong to your definition of the word. If so; why even be correct? In this case I believe this not to be the correct decision; because one should factor in the human-side of development too. If your ferrari's engine has been fixed using a piece of duck-tape; do you remove it and break said car because it is correct?

I for one do not intend to 'move' away from Chrome, because our customers won't and Chrome is still the best browser out there. But please; in your definition of 'correctness' factor in the human element a little more and revert this change or give us an alternative.

Comment 64 by gzjj...@gmail.com, Sep 28 2012

@Comment 32 by bunge...:

Regarding your reply to comment 20 by a..., please note that his native test happened without any change to the AppleFontSmoothing config, that's exactly the default (non-subpixel antialiased) rendering look like in OS X. I did the same test on my machine (also without any change to AppleFontSmoothing) as well, see attachment.

I'm especially confused about your comment "True, but you cannot rely on this. The dilation behavior is undocumented.", because it doesn't not require any undocumented behavior, since it IS the default behaviour.

Also, I'm curious about how Chromium actually rendered the so called unsubpixel-antialiased text. Since it's apparently not the OS native rendering, then you must be using something different than Core Graphics to render it.
Screen Shot 2012-09-28 at 12.32.10 PM.png
50.2 KB View Download
I work on JsFiddle.net and Positionly.com. I was completely caught off-guard by this radical change, can't really believe this is marked as a "Won't Fix", which is really just a slap in the face for all web-developers and designers depending on the workaround.

As being a developer and designer, I'm currently embarrassed by how both JsFiddle and Positionly look under Chrome 22 - I'd like you to take a moment and scan the attachments. Please notice that some words aren't even readable in Chrome 22. The word "Error" looks like "Emon", the words in green sections are barely readable. As noticed by someone above, 1 pixel shadows in most cases are no longer visible.

I believe the whole Chrome dev team is bunch of really smart guys, but it seems they lack to see the impact introduced by this change, and they never discussed any of this with the PR team (I assume there is one).

To me there's only one solution here, the "fix" gets reverted in 23, and we figure out what to do with this from there.
jsfiddle-21v22.png
76.8 KB View Download
positionly-21v22.png
82.3 KB View Download

Comment 66 Deleted

今天早上打开SF的网站(一个中文IT技术问答社区) http://segmentfault.com/   右边的链接变成了发黄的绿色了!我还以为我自己眼花了呢?最后从twitter上面搜索才发现原来是chrome版本更新的问题啊!!! 伤不起啊!!!!
中文的渲染真是惨不忍睹啊,google的工程师们你们这是要闹那样啊?!!!

plz Fix this!!!!!Chinese rendering is really appalling ah 


Snip20120928_25.png
177 KB View Download

Comment 68 by Deleted ...@, Sep 28 2012

I must say that as Web Designer, even if I understand your reasons, it's just turn my websites from beautiful to ugly. And difficult to read, which is the worst, causing users to leave. Thanks.

Comment 69 by skelt...@gmail.com, Sep 28 2012

Rather than argue that this change should never be applied, its opponents should be asking that the change be reverted and held in queue for a safer time.

What you've done is punch out the only stable solution to an important problem. What you should do is:
1. restore the solution (revert the change, harming no-one)
2. provide a new solution with an appropriate name (e.g. -webkit-font-rendering: faithful)
3. allow some time for web devs to add this new property
4. finally re-apply the change (restoring correctness without harming anyone)

Comment 70 Deleted

Comment 71 by woodh...@gmail.com, Sep 28 2012

Just adding another example of how this change causes a significant degradation in how text is rendered for us. 

We're not asking for much - just that your product continue to behave in the same way it has for years, or that failing that, you provide some sort of work-around that will allow us to recover the previous rendering behavior. 

In general, the response from the chrome team to this issue has come off as pedantic and somewhat obnoxious. Telling us that to be "correct" we should have millions of users  change low level operating system settings rather than provide a constructive remedy isn't helpful. 
save-chrome.png
11.4 KB View Download
Using windows 7 and since update 22 the most common used font sizes have all become faint and fuzzy. Really impossible to carry on using chrome, if this is not going to be changed. 

Comment 73 by Deleted ...@, Sep 28 2012

Chrome is an amazing browser and I appreciate the weight of these decisions, but with all respect, "WontFix" is a misstep. This thread makes it pretty clear that the only people who think this is a good thing are those on the Chrome team. I've attached yet another example of why this move should be reverted.
Screenshot of Google Chrome.png
41.9 KB View Download
Is there a reason this only seems to be happening with fonts included with @font-face? If I include Helvetica Neue with @font-face in a page I get the crappy aliased text, but then if I disable the @font-face to just go back to a default "sans-serif" system font (Helvetica on Mac), I get nicely anti-aliased text ala Chrome < 22.
@comment 74..
I think this is incorrect, an example I've been looking at (BCC News) is using Arial and is having the same problems.. I may have understood this incorrectly however.. so if this is wrong, I apologise..
Screen Shot 2012-09-27 at 15.19.28.png
106 KB View Download

Comment 76 by n...@helpscout.com, Sep 28 2012

I'd also like to raise my hand in opposition to the WontFix status. Thousands of web designers need to be posting on this thread, because we all noticed it. Our web app got uglier overnight just like the rest of the folks here. 

I'm all for change in the name of progress, even when it's painful, but this change is clearly not progress. Make whatever changes necessary to suit your roadmap and you won't hear a peep from me. I'll manually update everything we have. But don't take a valuable property away for seemingly no benefit. 

For those not holding your breath for this to be fixed, you can apply 400 or 600 weight to any bold text and get somewhat close to the desired result. I had to go through everything we have and manually adjust. It still doesn't look as good, but is better than nothing. 

Comment 77 by k...@google.com, Sep 28 2012

Labels: -Pri-2 Pri-1
Status: Started
OK folks, thanks for the comments here.  We're evaluating what the right course of action is, and will update this bug when there's anything new. 
I'm sorry I agree with the WontFix status. Developers clearly did not understand what webkit-font-smoothing actually did.

Please do not cave to the tyranny of the majority just because they didn't take the time to learn what the CSS rules they use actually are supposed to do.

Comment 79 by Deleted ...@, Sep 28 2012

@comment 78 :

It's not that we don't understand what font smoothing does. We realize that the font rendering on OSX was the unintended side effect of a bug in the webkit-font-smoothing code, and not its purpose.

What bothers us is that there is a long running font rendering issue with webkit and OSX, and no real fix. We used to be able to rely on that hack to get around it, now we don't even have that. 

@comment 77: Thank you for looking into this, much appreciated. 

Comment 80 by gouk...@gmail.com, Sep 28 2012

I also raise my hand against the wontfix status.

Not reverting the CSS rule to it's former behavior is one thing,
Removing the opportunity to get an acceptable rendering is another.

it seems to me that CSS has the goal of presenting content to the user (hence the "Style" in cascading style sheets)
Any update that changes the visual appearance of a web page should not be acceptable. If it went into a release version, it has to be considered public and hence stable.

The reasons for the change may be perfectly acceptable from a technical point of view, but css is visual, and technicalities are only secondary here.
The result is akin to pulling the carpet from under the designer's feet, a.k.a not good at all.

Also, we spent years raging against IE having bugs but also a different interpretation of CSS rules.
We finally have browsers that are coming to a consensus.

Please do not force designers to hack something around to get the rendering they want. That goes backward.

Comment 81 by k...@google.com, Sep 28 2012

Labels: ReleaseBlock-Stable
Could this antialiasing change be responsible for link colors in small text being off since v.22?

Have verified this same color abnormality on PC and Mac, Chrome 22 and Canary.
color.png
9.4 KB View Download

Comment 83 by k...@google.com, Sep 28 2012

OK folks, a quick update.  For Chrome 22, we're going to work to revert to the former behavior, and we'll be tackling how to fix the bug correctly in a later release.  We don't have a firm time that we'll push the update out yet, stay tuned.
Thanks a bunch. In particular, thanks for putting up with all the crap and drama in this thread.

Comment 85 by jcpar...@gmail.com, Sep 28 2012

@comment 83:

Excellent, thank you so much, kerz!

Comment 86 Deleted

@comment 83 by kerz@google.com:

Thanks kerz, it really is appreciated.



Whoa....... hold up.

I thought the bug was now fixed?
Isn't the heavier font dilation expected to exist even when that property setting was set?
Did I not correctly understand that there is no true webkit based rendering solution tied to CSS properties to fix this issue?
Isn't it an OS X LCD font smoothing issue that mac users need to turn off?

Whichever the solution SHOULD be .. I do appreciate the fast turn around. That in itself is commendable.
As a designer, this is really frustrating. I can't claim to understand all the technicalities discussed in this thread, but I do know this...

1). I spend 10 years learning my trade as a designer
2). I work really hard designing some websites
3). I spend countless hours making sure my designs are pixel-perfect on the web
4). Chrome updates
5). All the fonts look s**t in Chrome

I really hope there is some resolution to this soon, as Chrome is my browser of choice, and has been for a long time now, but it will drive me nuts if I have to keep looking at these terribly-rendered fonts!


Comment 90 by k...@google.com, Oct 1 2012

Cc: caryclark@chromium.org asvitk...@chromium.org
 Issue 152604  has been merged into this issue.

Comment 91 by Deleted ...@, Oct 2 2012

I was about to post this… It appears that in Chrome 22 they updated the rendering to not be as harsh on retina screens. I guess the thin fonts we're looking too thin on the retina screens. This update appears to have made the anti-aliasing appear to not have any effect. You can see this by changing from -webkit-font-smoothing: antialiased; to -webkit-font-smoothing: subpixel-antialiased; - it has no effect, but -webkit-font-smoothing: none; none does.

Please fix this!
 Issue 153396  has been merged into this issue.
Labels: Mstone-22

Comment 94 by k...@google.com, Oct 2 2012

Labels: Merge-Merged
Status: Fixed
This has landed, and will make it into our next updates for 22 and 23 on their respective channels when released.  Thanks for your patience folks.  We'll have more info about what we plan to do for 24 soon I expect.

Comment 95 by Deleted ...@, Oct 2 2012

Excellent! Thank you very much, and we look forward to the plans for 24.
@ Comment 94:

I would like to extend my thanks to the Chrome team. I, too, will look forward to hearing about the plans for 24. In the meantime, thanks for reverting this issue. When is the release of Chrome 23? November?
This is fantastic news. Thank you very much Chrome team. 
Very happy to hear this. Thanks so much for listening and taking everyone's feedback to heart.
Hooray for sanity!
Big thanks to the Chrome Team for making this decision. It's never an easy decision to scrap legitimately good (in this case technically "correct") work.

Comment 101 by Deleted ...@, Oct 4 2012

Awesome news! Thanks so much for fixing this. Curious, when do you think  22 and 23 will be released?
Agreed.. glad to see something is being done about this.. was driving me up the wall

Comment 103 by k...@google.com, Oct 8 2012

Heads up to folks following along here, the update for 22 with this reverted was just pushed this morning.

Comment 104 Deleted

Comment 105 by k...@google.com, Oct 8 2012

Can you report what version you have now?

Comment 106 Deleted

Comment 107 by k...@google.com, Oct 8 2012

This doesn't appear to be the same problem as mentioned above with fonts being too bold.  Can you file a new bug for this?
Version 22.0.1229.79
And it says it is up to date.

No changes in display; doesn't appear reverted.
kerz, it would help a alot to people following this issue if you told us what version of chrome fixes the issue.  My chrome says it is up to date, but fonts are still fat and ugly.

Comment 110 by k...@google.com, Oct 8 2012

Sure, 22.0.1229.92 should have the update.  If it says you have no update, try restarting entirely (make sure the app fully quits and is not running in the background) and restart.  All stable channel folks are being offered the update now on the Mac.
Was super hoping that the issue of text rendering in wrong/muted colors was related to this, but the update didn't have an affect. Hasn't been much activity on that bug:

http://code.google.com/p/chromium/issues/detail?can=5&start=0&num=100&q=&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20OS%20Area%20Feature%20Status%20Owner%20Summary&groupby=&sort=&id=146407
I'm not able to get 22.0.1229.92

I have restarted my computer 3 times and Chrome too.  It still says I am up to date with Version 22.0.1229.79

My OS is OS X 10.6.8

How do I get the update?
Same issue as folks above - Chrome isn't showing there's an update available.

That said, I've downloaded Chrome manually, and I can confirm the issue has been resolved. All fonts look as they used to.

Thanks a lot for this kerz!

Comment 114 by j...@moenig.org, Oct 9 2012

Interestingly today's minor OS X update for 10.8.2 seems to have fixed this issue for me, without having had to install an update for Chrome...

Comment 115 by Deleted ...@, Oct 9 2012

I was also experiencing this issue with Chrome 22.0.1229.79 on OS X 10.8.1 and 10.8.2. Chrome wasn't showing any updates available but like others I just re-downloaded Chrome and replaced it. It now reports the version number as 22.0.1229.92 and the issue is resolved.

Comment 116 by Deleted ...@, Oct 9 2012

Noticed rendering issue has different behavior on https:\\ vs Http:\\ loadings.
Designed website with Questrial that looks great on https: test server, but pixelated on normal http with Chrome and IE7
There is a new update for Chrome
Version 22.0.1229.92

It fixes this problem.

I had to download Chrome again and reinstall in order to get it to update.

Resolved.

Comment 118 Deleted

I am not happy with this change. Now fonts look thin when antialiased fonts are used compared to subpixel-antialiased fonts. This makes any text that "fades out" go thin, which is very jarring.

Example: http://jsfiddle.net/neave/KbpWA/ (view on Chrome Mac)

Notice how the second line of text is horribly degraded. Before this change the text looked identical. This change forces developers to use text-stroke hacks to regain the same thickness when using opacity on fonts.

This is a really stupid decision.

Comment 120 Deleted

Here is a screenshot of before (top text) and after (bottom text) on Chrome Mac 22.0.1229.92.

I defy anyone to say the bottom text looks better!
fonts-before-after.png
19.6 KB View Download
Thank you for the fix! At least for us, the problems we had are now gone and we're back to beautifully rendered glyph fonts, and nice rendering of Helvetica Neue and others which we use in our apps and which we had problems with lately. Thanks!
@Comment 119  and 121 by paul.ne...:

The issue you describe is what Chrome 22 was trying to fix, but that change was backed out of 22 and 23 due to -webkit-font-smoothing:antialiased and this issue specifically. A means of satisfying both is now in the latest Canary for Mac 24.0.1291.1. Starting with this Canary, regular antialiased text will match the lcd smoothed text, except when -webkit-font-smoothing:antialiased is used. (As a side note, this also applies to 'canvas'.)
@comment 123 Thanks for clarifying, Chrome Mac 24.0.1291.1 looks good, especially on canvas elements and opacity as you mention. M24 can't roll around soon enough!
I'm still seeing wrong color reproduction in both latest stable and canary builds. In my case, #1564c2 (used both for the link and the thick border below) has a purple tint when displaying text.

Setting -webkit-font-smoothing: antialiased fixes the perceptible color but text becomes too thin.
chrome-22.0.1229.94.png
4.8 KB View Download
chrome-24.0.1293.0.png
5.5 KB View Download
ff16.png
8.5 KB View Download

Comment 126 by p...@nehez.cz, Oct 17 2012

Please, take a look at the  issue #155462 , which I think is the same like this one but it is happening on Windows.

I started to dislike Chrome as fonts are so ugly.
adding html, body { -webkit-font-smoothing: subpixel-antialiased !important; } to Chrome's and/or Chrome Canary's Custom.css is temporary fix. Hope this issue gets resolved one way or another.

Comment 128 by p...@nehez.cz, Oct 29 2012

@Comment 127: It does not work in my Chrome 22.0.1229.94 on Windows 7 x64.

Any help how to fix this so annoying thing?
The chromium team still did not confirm  issue #155462 .

Comment 129 by Deleted ...@, Nov 1 2012

Version:22.0.1229.94 m
Windows 7 64 bit SP1
I am having the same issue the text looks distorted
issue.png
23.1 KB View Download
adding html, body { -webkit-font-smoothing: subpixel-antialiased !important; } to Chrome's and/or Chrome Canary's Custom.css, can not fix to me.
anyone know why?

Comment 131 by daz...@gmail.com, Nov 20 2012

Still happening for me. I've switched to Opera but I would like to see this resolved.

Windows 7; Chrome 23.0.1271.64 m

The 'good' text is IE. The 'bad' text is Chrome.
text.jpg
261 KB View Download
Hi, we have a similar issue, reported on #161734

Have you tried with an external monitor? 

On the same MBP, if we use an external display fonts are ok. Then we can move the chrome window back to MBP's display and it will be ok too. But as soon as you stop using the external display fonts becomes ugly.

Comment 133 by Deleted ...@, Dec 22 2012

This extremelly ugly font rendering still exist in Chrome 23 on Windows 7 x64. See the attached screen for Segoe rendering (the left one is IE9, followed by FF, right one is Chrome).
ie9-ff-chrome-fonts.png
104 KB View Download

Comment 134 by Deleted ...@, Jan 2 2013

on chrome 24 and still the fonts are poor on most sites.

Comment 135 by Deleted ...@, Jan 11 2013

I was also having this issue - I thankfully found a solution to the text flickering and wanted to share it in case anyone else was having similar troubles. My issue was when trying to have a jQuery wordpress slide show play with transition animations, and experiencing the webkit bug doing the text thinning during those transitions.

I've found this text issue happening only on Mac in both Chrome and Safari - it turns out it is a well known bug with the webkit engine for Macs, where it is trying to optimize the performance and causes a thinning of text in and sometimes to peripheral text / text around the slideshow, on the slide areas. That's what makes the flickering happen during animations and transitions. 

To FIX this issue, you need to add some code to the CSS style sheet.

This is the code I added to fix the flickering - note - this fixes it in both Chrome AND Safari - but for me, it added some additional issues in Safari, which I will explain after this:

body .site {
-webkit-font-smoothing: subpixel-antialiased !important;
-webkit-backface-visibility: hidden;
-moz-backface-visibility:    hidden;
-ms-backface-visibility:     hidden;
}

This should make sure text smoothing looks good but also the key part is that -webkit-backface-visibility: hidden; line - THAT will be what really helps smooth out the flickering of text.

BUT while seeming to fix it completely in Chrome, it caused a few issues for me in Sarafi. I've added some CSS elements in my Child theme to customize my theme and these elements are positioned with CSS using z-index positioning to fall OVER the slide show. Well, once applying this fix, the elements I had made over the slideshow were now flickering as the active slides moved over the top-positioned elements temporarily during transition, I guess because they were becoming active and adding that webkit fix had disabled it looking like it was staying in place. But, I found out by adding the line of code below to the elements I was wanting to stay in place and NOT get covered / flicker, it worked to fix this issue too:

-webkit-backface-visibility: hidden;

If you add that line of CSS to the elements in front of the slideshow it will make sure your image slides don't pop to the front and cover these top elements.

Now my text is no longer looking flickery on my slide transition animations. Hope this helps someone else!

Comment 136 Deleted

Comment 137 by Deleted ...@, Jan 17 2013

Hi All,

PARTIAL SOLUTION

It seems like this is especially (but not always) an issue when @font-face is being used. If you're a developer using font replacement with something like Font Squirrel try putting the .SVG format immediately after the .EOT IE fixes. This immediately fixed the rendering for me and doesn't require any further fixes.

I know this doesn't help everyone but hopefully someone will find it useful.


#137 I applied this fix and was happy for a while.. until my colleagues experienced content overlaps, shifts and weird behavior. And doesn't happen all the time, only from time to time. Looks like it has to be changed back. 
Project Member

Comment 139 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Area-WebKit -Type-Regression -WebKit-Fonts -Mstone-22 Cr-Content Type-Bug-Regression Cr-Content-Fonts M-22
Project Member

Comment 140 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 141 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Fonts Cr-Blink-Fonts

Comment 142 by mgt...@gmail.com, Jun 28 2013

font-face rendering in chrome is an embarrassment on osx and windows with font-face. 

using svg for font-face helps, at the cost of it being slightly less efficient. wott is not working well though.

really hope this get some chrome devs attention. 

BTW: Of course its a none-issue on a retina-like high-dpi display. but most actual users dont have that yet.

Comment 143 by Deleted ...@, Jun 28 2013

#138 Yep, same for me. Used that fix, and I get different render results from time to time. As I can see it happens only when I use "float: right" or "text-align: right".
chrom-gone-crazy.png
16.0 KB View Download

Comment 144 Deleted

Comment 145 Deleted

Comment 146 Deleted

2014. Still the same issue. Shame of the 21st century that Chrome developers force anti-aliasing upon us. I have found NO SIMPLE AND SUITABLE WAY turning this 5h1t off. By 5h1t I mean the WebKit font smoothing. Looks ugly, makes the text more unreadable, consumes a lot more resources. Thank you for the bloat! Please provide me a way to REMOVE THIS!
I'm using Wordpress & the Google font Raleway and a user send me the attached example how it looks like on his site.


raleway-in-chrome.jpg
18.7 KB View Download
Showing comments 49 - 148 of 148 Older

Sign in to add a comment