Checked beta channel, this is present there as well.

I used a Gimp to create a picture that shows difference between your two screenshots of m59 and m60.

But the result says rendered images are completely same thing.

So, let me close this as WontFix.

Deleted: subtract60from59.png 2.1 KB

	subtract60from59.png 2.1 KB View Download

My apologies; this bug is definitely present if I do a side-by-side comparison of beta channel and M59. I may just have been imagining it in the screenshot, however, which could imply that it's a subpixel or other rendering artifact not picked up in the screenshot.

I'll see if I can provide a better demonstration for you.

Here are two photographs. If you look closely on the M60 one, you can clearly see that it has increased blending, such as inside each lowercase m.

Can you please reopen this bug?

Deleted: M59 fonts.jpg 277 KB

	M59 fonts.jpg 277 KB View Download

Deleted: M60 fonts.jpg 262 KB

	M60 fonts.jpg 262 KB View Download

Removing Blink>WebFonts, this is not a webfont issue.

I can see changes in lowercase m and position of the dot in '0'.
It indeed looks like a subpixel rendering issue.

+eae, would you help triaging this?

Tested the issue on ubuntu 14.04 and Mac OS 10.12.6 using chrome M60 #60.0.3112.113 and reported M59 #59.0.3071.86 and observed the fonts as attached in the screenshots.

Unable to figure out the difference in both the versions of chrome.

@ alercah-- Could you please provide us any sample test case or jsfiddle that reproduces the issue , for better traiging.

Thanks!

Deleted: 759335_m59.png 197 KB

	759335_m59.png 197 KB View Download

Deleted: 759335.png 219 KB

	759335.png 219 KB View Download

Unfortunately I don't have a specific case. I've noticed this on most pages though; I don't think there are particularly unusual conditions to trigger it.

May I ask some more questions?

- Could you provide information about the display you are using with your Linux, such as manufacturer name, product name, screen resolution, etc?
- Could you reproduce the problem with another display?
- Could you reproduce this with a clean profile, without any extension, i.e. in guest session, using new profile, or launching chrome with --user-data-dir=/tmp/foo
- More specific version of your debian, i.e. result of "uname -v"

It's the builtin LCD for a Lenovo T440p. I can't easily test wth another display right now, but I'll get back to you if I can. It reproduces on a clean profile. uname -v gives #1 SMP Debian 4.9.30-2 (2017-06-12)

Any luck? Anything else I can do to help this? 

Does Chrome switch back to the old rendering style if you export FREETYPE_PROPERTIES="truetype:interpreter-version=35" in your environment? Just want to make sure that this is the same thing being discussed in  issue 760593 .

It may be, as the M60 text in #6 does appear to have less/no horizontal hinting than the M59 screenshot. It's also possible that something else is wrong, as some parts of the M60 screenshot seem quite bad -- compare the "1. Upgrade" text between the two, for example.

Yes, it seems to work properly this way; the Freetype bug linked in the other thread also indicates that a fix is forthcoming so hopefully if you are able to upgrade to the new version ASAP then it will be fully resolved.

If you're referring to http://savannah.nongnu.org/bugs/?func=detailitem&item_id=51051 or http://savannah.nongnu.org/bugs/?func=detailitem&item_id=51387, those are just about non-antialiased text, which doesn't seem to be what you're using in your screenshots. Is there another FreeType bug report tracking changes to antialiased rendering?

Ah hmm, you may be right. I haven't looked for other bugs.