Is this problem caused by switching from GTK2 to GTK3?

 Issue 726632  has been merged into this issue.

> Is this problem caused by switching from GTK2 to GTK3?
No because this is on Chrome 58

Tested this issue on ubuntu 14.04(GTK Version : 3.10.8-0ubuntu1.6) with chrome #59.0.3071.86 

From settings->Fonts changed the font to verdana and increased size to 14 

Didn't observe any font rendering issues.

Attaching screen-cast for reference.

omyslivets@ could you please look into it and let us know any steps i have missed while reproducing the issue.

Thank You...

Deleted: Issue 726631.mp4 1.7 MB

	Issue 726631.mp4 1.7 MB View Download

I have the same issue on Chrome 60 since today: my fontconfig settings seem to be ignored, resulting in awful rendering.

Attaching screenshots of comparisons between Chrome 59 and 60, where the problem is evident.

Deleted: Screenshot from 2017-06-12 10:18:55.png 62.6 KB

	Screenshot from 2017-06-12 10:18:55.png 62.6 KB View Download

Deleted: Screenshot from 2017-06-12 10:18:10.png 12.6 KB

	Screenshot from 2017-06-12 10:18:10.png 12.6 KB View Download

Deleted: Screenshot from 2017-06-12 10:19:37.png 53.4 KB

	Screenshot from 2017-06-12 10:19:37.png 53.4 KB View Download

can confirm with 60.0.3112.24 and font which is probably non-anti-aliased Arial

Deleted: Screenshot_2017-06-16_19-24-22.png 34.1 KB

	Screenshot_2017-06-16_19-24-22.png 34.1 KB View Download

correct rendering with 59.0.3071.86 

Deleted: Screenshot_2017-06-16_19-40-28.png 32.2 KB

	Screenshot_2017-06-16_19-40-28.png 32.2 KB View Download

@ kkaluri@chromium.org

Hi.

There is no problem on 'Chromium'. Chromium works just fine. The problem exists on 'Chrome' from Google repository. These are two different browsers.

The Chromium browser is this one:

root@debian:~# apt-cache show chromium
Package: chromium
Source: chromium-browser
Version: 59.0.3071.86-1
Installed-Size: 189355
Maintainer: Debian Chromium Maintainers <pkg-chromium-maint@lists.alioth.debian.org>
Architecture: amd64
Provides: gnome-www-browser, www-browser

While the Google browser is this:

root@debian:~# apt-cache show google-chrome-beta
Package: google-chrome-beta
Version: 60.0.3112.32-1
Architecture: amd64
Maintainer: Chrome Linux Team <chromium-dev@chromium.org>
Installed-Size: 270337
Pre-Depends: dpkg (>= 1.14.0)
Depends: gconf-service, libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.15), libcairo2 (>= 1.6.0), libcups2 (>= 1.4.0), libdbus-1-3 (>= 1.1.4), libexpat1 (>= 2.0.1), libfontconfig1 (>= 2.11), libgcc1 (>= 1:4.1.1), libgconf-2-4 (>= 3.2.5), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.28.0), libgtk-3-0 (>= 3.3.16), libnspr4 (>= 2:4.9-2~), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 4.8.1), libx11-6 (>= 2:1.4.99.1), libx11-xcb1, libxcb1 (>= 1.6), libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxrandr2 (>= 2:1.2.99.3), libxrender1, libxss1, libxtst6, ca-certificates, fonts-liberation, libappindicator1, libnss3 (>= 3.17.2), lsb-release, xdg-utils (>= 1.0.2), wget
Provides: www-browser
Section: web
Priority: optional
Filename: pool/main/g/google-chrome-beta/google-chrome-beta_60.0.3112.32-1_amd64.deb
Size: 67132004
SHA256: 57f4a7cbf100b32f875abd99b97dd133eb64e7161fc5e461b8c2f34c51735c7e
SHA1: 1a0973cfb81c15ec64a9fd15855d934a05ddcc51
MD5sum: b47a8e22c5443bba46cc38a210737ddc
Description: The web browser from Google
 Google Chrome is a browser that combines a minimal design with sophisticated technology to make the web faster, safer, and easier.
Description-md5: a2d34067fc33f1c87253c33b9fd975f0



To check the problem you have to install a Google browser. Add the following line to your /etc/apt/sources.list

deb http://dl.google.com/linux/chrome/deb/ stable main

and install the google browser:

apt-get install google-chrome-beta

Also I have no systemd (sysv-rc init system is used) and no GUI login screen (GDM, ligthdm or the like).

X server is started from 'text-mode' console by xinit. No gsettings or other GNOME-related programs are running. Only dbus and udev (systed-udevd daemon) are running aside usual cron, rsyslog and networking.

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@kkaluri in #5 you tested Chrome 59, where I'm not seeing the issue.

Chrome 60 does exhibit this behaviour fairl consistently. I am using a custom fontconfig (in ~/.config/fontconfig/fonts.conf) which might expose this issue, here it is in case you want to replicate

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="font">
        <edit name="antialias" mode="assign">
            <bool>false</bool>
        </edit>
        <edit name="hinting" mode="assign">
            <bool>true</bool>
        </edit>
        <edit name="hintstyle" mode="assign">
            <const>hintslight</const>
        </edit>
        <edit name="rgba" mode="assign">
            <const>rgb</const>
        </edit>
        <edit name="autohint" mode="assign">
            <bool>false</bool>
        </edit>
        <edit name="lcdfilter" mode="assign">
            <const>lcdnone</const>
        </edit>
        <edit name="dpi" mode="assign">
            <double>102</double>
        </edit>
    </match>
</fontconfig>

Also the issue was introduced somewhat close to version upgrade from 59 to 60. I've used 59.x for a while without this glitch (or whatever it is). I've bumped into the issue once I've update google-chrome-beta to 60.x

Unable to reproduce the issue on Ubuntu 14.04 with chrome #59.0.3079.104 and latest dev #61.0.3135.0

As mentioned, Issue is related to OS Version: Linux Debian 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux,Linux Debian is not available to test the issue with HYD chrome-TE team, passing to MTV team for further triage.

Thanks!

As the issue affects the rest of your system and isn't limited to Chrome it would suggest a system configuration problem rather than a Chrome one. The chrome font configuration has no way of influencing system applications or GTK apps.

I can see this issue only with Chrome 60.
Chrome 59 and other GTK apps aren't affected.

I don't wanna be rude but I felt like some of @chromium.org people somehow fail to read plain English. I hope that's not a some sort of trolling...

So I've made one more picture to demonstrate the issue. You might see on the picture TWO VERSIONs OF CHROME(IMUM) - stable 59.x and beta 61.x - at the same time.

Also there are pictures of GTK3 application Transmission and GTK2 application Leafpad.

None of GTK 2/3 programs have a problem with either fonts or fontconfig.

The *ONLY* program which have a problem with fonts is beta version of Google Chrome from Google deb-repo.

Deleted: chrome-beta-fontconfig-issue.png 86.8 KB

	chrome-beta-fontconfig-issue.png 86.8 KB View Download

In your original report you explicitly stated, and I quote:

"What went wrong?
Font rendering is broken both in the GTK GUI and web-pages."

That is also the summary for the bug report itself.

Is that no longer the case?

I'm not the original reporter, but I reported the same symptoms with screenshots comparing 60 to 59 in comment #6: the issue is in how Chrome 60 renders font both in content and its title bar.

But as any other app on the system renders fonts correctly, and Chrome 59 does too, it's pretty evident it's not a gtk or system-wide problem.

What you (eae) state in #14, that "the issue affects the rest of your system and isn't limited to Chrome" is not what is being reported here, rather the opposite.

If you need any system data or screenshot just ask, of course!

@ e...@chromium.org

> Is that no longer the case?

This is the case. Yet the issue is reported against beta Chrome 60.x, not against any other program.

So the GUI in the report belongs to Google Chrome.

Google Chrome as well as opensource Chromium has a GUI part aside web page rendering itself - "Save as" dialog. This dialog is part of Google Chrome program.

You may find both 59.x and 60.x Chrome(ium) "Save as" dialog screenshots in the original report.

And again just in case - any other GTK2/3 program doesn't have any issue with font rendering using the very same "File open/close" dialog window.

Please, feel free to ask any additional questions if anything is unclear.

Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Would you mind supplying your font config file?

Sure. Please, note, you'll need to replace '/path/to/ttf' by the full path to *.ttf files as per your machine in '<dir>' directive at line 16.

Also, you'll have to put some ttf files to the location of course. You may use 'msttcorefonts' package to download files from the web or pick them up from the nearest MS Windows installation.

Deleted: fonts.conf 2.3 KB

fonts.conf 2.3 KB Download

Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note that Chrome's UI hasn't been rendered using GTK+ for years, which is probably the reason for confusion earlier in the bug.

I don't know what could've changed on the Chrome side, but from the screenshots, I think that the text is unhinted (or lightly hinted) in conjunction with antialiasing being disabled. This is what the config in #11 is requesting, and it's known to look terrible -- Cairo ignores this combination, IIRC.

Here's the code in ui/gfx/font_render_params_linux.cc that tries to work around this in a similar manner:

  if (!params.antialiasing) {
    // Cairo forces full hinting when antialiasing is disabled, since anything
    // less than that looks awful; do the same here. Requesting subpixel
    // rendering or positioning doesn't make sense either.
    params.hinting = FontRenderParams::HINTING_FULL;
    params.subpixel_rendering = FontRenderParams::SUBPIXEL_RENDERING_NONE;
    params.subpixel_positioning = false;
    ...

Does the problem go away when you change "hintstyle"'s value to "hintfull" and restart Chrome?

(Your config is also requesting subpixel antialiasing via the "rgba" property, which doesn't make sense in conjunction with AA being disabled.)

derat, thanks for having a look at this. Changing hintsyle to hintfull makes absolutely no difference (and does not explain why Chrome 59 is perfectly fine).

Please build and run https://github.com/derat/font-config-info and attach the output here. It's possible that something else is overriding the settings from fontconfig.

also tried font-config-info:

GtkSettings:
gtk-font-name        "Arial 9"
gtk-xft-antialias    0 (no)
gtk-xft-hinting      -1 (default)
gtk-xft-hintstyle    "hintfull"
gtk-xft-rgba         "rgb"
gtk-xft-dpi          98304 (96.00 DPI)

GTK 2.0 styles:
GtkLabel             "Arial 9"
GtkMenuItem          "Arial 9"
GtkToolbar           "Arial 9"

GSettings (org.gnome.desktop.interface):
font-name            "Cantarell 11"
text-scaling-factor  1.00

X11 display info:
screen pixels        1920x1080
screen size          508x285 mm (96.00x96.25 DPI)

X resources (xrdb):
Xft.antialias        "0"
Xft.hinting          [unset]
Xft.hintstyle        "hintfull"
Xft.rgba             "rgb"
Xft.dpi              [unset]

XSETTINGS:
bash: dump_xsettings: command not found
Install dump_xsettings from https://code.google.com/p/xsettingsd/
to print this information.

Fontconfig (Arial 9):
requested size       9 points
family               Arial
pixelsize            9.38 pixels
size                 9 points
antialias            0
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (default pattern):
antialias            [no match]
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (default match):
family               Arial
pixelsize            12.50 pixels
size                 12 points
antialias            0
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

Fontconfig (non-family/size defaults):
antialias            0
hinting              1
autohint             0
embeddedbitmap       1
hintstyle            3 (full)
rgba                 1 (rgb)

My fontconfig info output attached.

Deleted: font-config.txt 1.8 KB

font-config.txt 1.8 KB View Download

> which is probably the reason for confusion earlier in the bug.

Nah. The source of confusion was misreading the term 'GUI' as a system wide interface rather then what GUI is stand for.

> Note that Chrome's UI hasn't been rendered using GTK+ for years,

I'm sure, that was an attempt to help, yet unfortunately it add a bit of confusion to the contrary.

The font rendering on Linux is made by freetype library from the start of the Chrome project.

The UI elements of Chrome on Linux are made by GTK library. Well, at least my copy of Google Chrome does:

$ ldd /opt/google/chrome-unstable/chrome | sort 
...
	libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fb0f3dad000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fb0f0b1c000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb0f1584000)
	libgconf-2.so.4 => /usr/lib/x86_64-linux-gnu/libgconf-2.so.4 (0x00007fb0f392c000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fb0ea5ed000)
	libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007fb0f1d40000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fb0f1b1d000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fb0f3594000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fb0f6840000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fb0f4e85000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb0ead34000)
	libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fb0eeb95000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fb0f6b54000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fb0e9d33000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007fb0e9f47000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fb0eef2e000)
	libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fb0f0fe1000)
	libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007fb0f2037000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007fb0eca14000)
...

> Please build and run https://github.com/derat/font-config-info and attach the output here. 

Thanks for the links (and, probably, the program itself?).

Yet the thing is, that being a separate GTK prorgam it will report the fontconfig configuration as it seems by any other GTK program. Which means it will report no problem at all since GTK programs doesn't have any issues with fonts.

The only program which does.. Well, you know.

This is easy to repro in a ToT Linux build at r484344. Dump the following in ~/.fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="antialias" mode="assign"><bool>false</bool></edit>
    <edit name="autohint" mode="assign"><bool>false</bool></edit>
    <edit name="hinting" mode="assign"><bool>true</bool></edit>
    <edit name="hintstyle" mode="assign"><const>hintfull</const></edit>
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>
</fontconfig

With some logging in ui/gfx/font_render_params_linux.cc, I can see that GetFontRenderParams() is returning the requested settings (hinting "3" corresponds to "FULL"):

[103762:103762:0705/155205.743539:ERROR:font_render_params_linux.cc(293)] XXX GetFontRenderParams: families=Sans pixel_size=0 point_size=10 dsf=0 adsf=1
[103762:103762:0705/155205.743645:ERROR:font_render_params_linux.cc(299)]     antialiasing=0
[103762:103762:0705/155205.743657:ERROR:font_render_params_linux.cc(300)]     hinting=3
[103762:103762:0705/155205.743668:ERROR:font_render_params_linux.cc(301)]     subpixel_rendering=0
[103762:103762:0705/155205.743681:ERROR:font_render_params_linux.cc(302)]     subpixel_positioning=0

Both the UI and web content looks like it's unhinted, though -- see the attached screenshot.

enne@, any ideas? I'm not familiar with the current text rendering path, but it looks like gfx::RenderText goes through gfx::internal::SkiaTextRenderer, which goes through cc::PaintCanvas, which probably does some other stuff eventually involving Skia. Maybe the hint flag is getting dropped somewhere around there, or something is Skia changed so that hinting is disabled when antialiasing is disabled, or ...?

Deleted: snap-155837.png 17.4 KB

	snap-155837.png 17.4 KB View Download

I tried bisecting using the instructions from comment #31 and the fonts like equally bad so far as I can tell even back in like r358546 (m48).  Maybe those instructions are not a repro for the original bug, or I'm missing something?

Ok, looking at the settings page in particular and the poorly hinted o's in bookmarks, led me to https://chromium.googlesource.com/chromium/src/+log/e85944f082b27f903fcea5491549de058e157528..6cb36ccfdb9a811a5839677d894595d79ed5b8af, which by manual testing turns out to be the material design in the settings page that exposed/created this bug: https://chromium.googlesource.com/chromium/src/+/a8109d958f144e541a204da6debd820d936d6108

This does not sound like the original bug, however.

In terms of where this ends up, most of the UI rendering code ends up through PaintOpBuffer's DrawPosText::RasterWithFlags and calls SkCanvas::DrawPosText.

Printing things out on the SkPaint that's going into Skia, I see what's in the fontconfig, i.e. hinting=3 and autohinted=false.

Thanks for looking at this, enne@!

After messing with it some more, I believe that only some fonts are affected. For example, in my ToT build, Arial still looks fine, both in the UI and in web content. Roboto (used in MD settings) looks awful when it's not antialiased, though -- it appears to be unhinted.

Roboto looks terrible in Chrome 59 as well, though.

Deleted: ui-arial-content-arial.png 15.9 KB

	ui-arial-content-arial.png 15.9 KB View Download

Deleted: ui-arial-content-roboto.png 12.6 KB

	ui-arial-content-roboto.png 12.6 KB View Download

Deleted: chrome-59.png 13.1 KB

	chrome-59.png 13.1 KB View Download

I get similar results from gedit 3.10.4 when I disable antialiasing: Unhinted-looking text when the UI font is set to "Sans 10", but hinted text when it's "Arial 10".

I suspect that any changes in Chrome's fonts were caused by switching from GTK2 to GTK3, which happened in M59 ( issue 79722 ). I think that comment #4 may be a bit off -- the initial report also mentions M60.

For users who are seeing bad font rendering, particularly in the UI, it'd be interesting to see screenshots of Chrome's UI text alongside that of gtk-demo (GTK2 app available via the gtk2.0-examples Debian/Ubuntu package) and that of gtk3-demo (GTK3 app from gtk-3-examples).

Also, I missed that the initial report also showed vastly-differing file dialog screenshots. As far as I know, these are just native GTK dialogs and Chrome doesn't have any input to how text is rendered in them. That supports the theory that this is just from the switch from GTK2 to GTK3.

Deleted: gedit-sans-10.png 7.8 KB

	gedit-sans-10.png 7.8 KB View Download

Deleted: gedit-arial-10.png 7.7 KB

	gedit-arial-10.png 7.7 KB View Download

Derat, attached a side by side comparison of (in order) Chrome 59, Chrome 60, gtk-demo, gtk3-demo.

Deleted: chrome_comparison.png 40.2 KB

	chrome_comparison.png 40.2 KB View Download

Both 59 and 60 use GTK3, but 60 is broken and 59 isn't.

Not sure why both #39 and #40 were deleted, but they mentioned issue 732731, which describes how Chrome M60 statically links FreeType 2.7.1, which also switches to hinting interpreter v40. Dominik, any chance that that change could be responsible for the non-AA hinting regression that's discussed here?

For what it's worth, I still see the problem in a ToT build when I set the FREETYPE_PROPERTIES environment variable (described in  issue 649362 ) to "truetype:interpreter-version=35".

ludomagno@, thank you for the comparison screenshot and earlier font-config-info output! Just to check, what version of FreeType do you have installed (e.g. output of "dpkg -l 'libfreetype*' | grep ^ii" if you're on Debian or Ubuntu)?

Derat, I'm on Ubuntu, and freetype is 2.5.2-1ubuntu2.8

I'm on Debian 9.0 and my libfreetype6 is 2.6.3-3.2

> For what it's worth, I still see the problem in a ToT build when I set the FREETYPE_PROPERTIES environment variable (described in   issue 649362  ) to "truetype:interpreter-version=35".

Setting the variable to this option **SOLVE** the problem in my case.

Once I've set up the variable:
$ export FREETYPE_PROPERTIES="truetype:interpreter-version=35"

and start the browser:

/usr/bin/google-chrome-unstable --disk-cache-dir="/tmp/nonexisted" --media-cache-dir="/tmp/nonexisted"  --disable-remote-fonts

I've got pages rendering identical to the Chromium from Debian repo.

This also fix font rendering in GTK dialogs, created by Chrome.

Also, the new 'Topic name' of the bug is incorrect.

In the images I've posted in bug description only small glyph are not antialiased.

The large ones **ARE ANTIALIASED** according my fontconfig settings, posted at #22. Large glyph of antialiased fonts are rendering wrong as well.

Please find attached a screenshot showing the difference and an htlm file used to make screenshot. The upper part is Chromium 59.x, the one at the bottom - Chrome 61.x with  'FREETYPE_PROPERTIES' variable unset.

(Please note: in case your display is unable to render a line with single pixel precision you may need to increase the picture to see unexpected 'grey lines' alongside with vertical strokes of 'H' and 'l' letter on 61.x rendering.)

Deleted: test.html 179 bytes

test.html 179 bytes View Download

Deleted: Times New Roman Comparison.png 22.5 KB

	Times New Roman Comparison.png 22.5 KB View Download

I believe this is now fixed with

https://chromium-review.googlesource.com/c/550379/

particularly by rolling in the FreeType change 

2017-05-20 madigens [truetype] Always use interpreter v35 for B/W rendering (#51051)

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=a0455468fdb8dd1959596d0c8c8a3ff07ee495a3

This means the fix is coming to Chrome and default build Chromium. Note that it is possible for distributions to build Chromium against the system FreeType library, so if that library is in the range 2.7.0 and 2.8.0 (inclusive) then this issue will appear and 

$ export FREETYPE_PROPERTIES="truetype:interpreter-version=35"

will be needed as a work-around. However, when that is the case, the rest of the system's aliased glyphs will also look poor without the FREETYPE_PROPERTIES set.

As to comment #47, if you're having issues with large glyphs being anti-aliased when it is expected that they should be drawn aliased, I believe that is a separate issue from the rest of this. I do know there was a recent issue with glyphs drawn by the GPU sometimes not being aliased when they should be, so the issue described in comment #47 could quite possibly be  issue 707979 .

Is there any way to backport the fix to M60? I just got bitten by this on the stable channel. Exporting FREETYPE_PROPERTIES="truetype:interpreter-version=35" fixed it, but it isn't scalable. :-)

re: comment 50
Daniel, you still have this issue even though anti-aliasing is enabled? With what fonts?  Roboto 2.132 on my Linux box is fine in settings page. 

Yes, I have grayscale AA enabled with full hinting. In 60.0.3112.78, I'm seeing this with all fonts. Here's the relevant portion of my .fonts.conf; I'm requesting matching settings through XSETTINGS/GTK+:

    <edit name="antialias" mode="assign"><bool>true</bool></edit>
    <edit name="autohint" mode="assign"><bool>false</bool></edit>
    <edit name="hinting" mode="assign"><bool>true</bool></edit>
    <edit name="hintstyle" mode="assign"><const>hintfull</const></edit>
    <edit name="rgba" mode="assign"><const>none</const></edit

I'm using "Sans 10" as my UI font, which FontConfig maps to DejaVu Sans. It looks like we're ignoring my request to use full hinting. I don't know whether we're using the LAH instead or still using the BCI.

actual.png was taken in the same version of Chrome after exporting FREETYPE_PROPERTIES="truetype:interpreter-version=35". It's the same as what I was seeing in 59.

Deleted: actual.png 140 KB

	actual.png 140 KB View Download

Deleted: expected.png 125 KB

	expected.png 125 KB View Download

What do you get for `fc-match -v 'DejaVu Sans'`?  I got this: (haven't tried DejaVu Sans in html, yet in Chrome 60 ). 

        antialias: True(w)
        hintstyle: 0(i)(w)
        hinting: False(w)
        verticallayout: False(s)
        autohint: False(w)
        globaladvance: True(s)
        file: "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"(w)

FontConfig returns the same settings I asked for:

        antialias: True(w)
        hintstyle: 3(i)(w)
        hinting: True(w)
        verticallayout: False(s)
        autohint: False(w)
        globaladvance: True(s)
        file: "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"(w)

Thanks. 

Perhaps, ft-demo (with FT 2.8.0 and the one  ToT) programs should be used to see how DejaVuSans is rendered with anti-aliasing on and BCI on (with different engine versions). 

 Issue 748997  has been merged into this issue.

This is a request to merge the FreeType roll https://chromium.googlesource.com/chromium/src/+/4d6320ef3dee4ac9f29055b6b9d75497ea67796f to M60

and the pre-requisite Skia change https://skia.googlesource.com/skia/+/6cdb5f2ad7684302a8a66217462d2aef4c5f4632 to Skia's m60 branch.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note that both of these changes have been in M61 for quite some time (since well before it was branched).

To summarize the issue: users on M60 on Linux using aliased font rendering are currently getting very light hinting instead of full hinting due to a change in FreeType. The FreeType roll includes a fix for this. Unfortunately, this FreeType roll also includes a change in behavior which necessitates pulling in the Skia change.

Thanks, Ben!

Thinking about this a bit more, I'm surprised that it wasn't caught by any Blink layout tests. I'm pretty sure I've seen ones exercising different hinting settings in the past. Do those still exist?

The FreeType roll did fix a layout test, see the png which changed in https://chromium-review.googlesource.com/c/550379/ (the CL for that roll). This was (I believe) the first roll after the very large rebaseline from moving the layout tests to a much newer FreeType revision. When the big relayout was done this one change wasn't noticed as an issue. Now that we're rolling FreeType more frequently and in smaller increments we are more aware of when there are changes.

Re #64: fast/text/chromium-linux-fontconfig-renderstyle.html does still exist.

Thanks++ Ben!

 Issue 749271  has been merged into this issue.

The changes in #59 meet the bar and are approved for merge into M60.  Given the severity of the bug, and that they've been on M61 for over a month without problems.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/d1f2d15b36f6a6a9d199581b998a7ca924a1f1a8

commit d1f2d15b36f6a6a9d199581b998a7ca924a1f1a8
Author: Ben Wagner <bungeman@behemoth.cnc.corp.google.com>
Date: Fri Jul 28 19:49:23 2017

Clip FreeType glyph bitmap to mask.

Skia has for some time assumed that when using FT_Render_Glyph with one
of the LCD render modes that one extra pixel would be applied to each
side of the resulting bitmap. FreieType has changed to make this more
conservative when possible, so the pre-allocated SkMask and the generated
FT_Bitmap may no longer agree on the size and origin.

This change ensures the SkMask and FT_Bitmap are the same size and their
origins align. This is not an ideal long term fix, but is both simple and
localized for easy and quick back-porting, should that become necessary.

BUG=skia:6663

Original-Change-Id: I49ec8f45376be8d867e8aef54eab79537731c310
Reviewed-on: https://skia-review.googlesource.com/20327
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>

BUG= chromium:726631 

Change-Id: I9740bc7df544b402720caaf97244ff1fb05f3b81
Cherry-Pick: 6cdb5f2ad7684302a8a66217462d2aef4c5f4632
Approval:  https://crbug.com/726631#c69 
Reviewed-on: https://skia-review.googlesource.com/28185
Reviewed-by: Ben Wagner <bungeman@google.com>

[modify] https://crrev.com/d1f2d15b36f6a6a9d199581b998a7ca924a1f1a8/src/ports/SkFontHost_FreeType_common.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5bb2255a4efdc1284b9c8775c65c03f11c099627

commit 5bb2255a4efdc1284b9c8775c65c03f11c099627
Author: Ben Wagner <bungeman@chromium.org>
Date: Fri Jul 28 20:02:09 2017

Roll src/third_party/freetype/src/ a12a34451..7819aeb62 (58 commits)

https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+log/a12a34451a99..7819aeb622a9

$ git log a12a34451..7819aeb62 --date=short --no-merges --format='%ad %ae %s'
2017-06-28 bungeman Avoid Microsoft compiler warnings (#51331).
2017-06-27 wl * src/cff/cffparse.c (do_fixed): Fix typo.
2017-06-27 wl [truetype] Integer overflows.
2017-06-24 wl [truetype] Integer overflows.
2017-06-22 wl [cff, truetype] Integer overflows.
2017-06-21 apodtele [sfnt] Synthesize a Unicode charmap if one is missing.
2017-06-20 wl Remove deprecated comment.
2017-06-20 tonyt Fix pkg-config in freetype-config for cross-compiling (#51274).
2017-06-20 wl [cff, truetype] Integer overflows.
2017-06-17 apodtele [base, smooth] LCD filtering cleanups.
2017-06-16 wl [truetype] Integer overflows.
2017-06-15 wl [bdf, cff] Integer overflows.
2017-06-14 wl * src/winfonts/winfnt.c (FNT_Face_Init): Don't set active encoding.
2017-06-13 wl [cff, truetype] Integer overflows.
2017-06-11 wl [cff] Integer overflows.
2017-06-10 wl [truetype] Fix TT_Set_Var_Design.
2017-06-10 wl * src/base/ftcalc.c (FT_DivFix): Fix embarrassing typo.
2017-06-09 wl [cff, truetype] Integer overflows.
2017-06-09 wl Provide more macros for flooring, ceiling, and rounding.
2017-06-09 wl Remove unused macros.
2017-06-09 wl */*: Remove `OVERFLOW_' prefix.
2017-06-07 wl [cff, truetype] Integer overflows.
2017-06-06 wl [cff] Integer overflow.
2017-06-05 wl [cff] Integer overflow.
2017-06-04 wl [cff, truetype] Integer overflows.
2017-06-03 wl [base, cff, truetype] Integer overflows.
2017-06-03 wl * builds/unix/freetype-config.in: Fix pkg-config test (#51162).
2017-06-03 wl [bdf] Synchronize sanity checks with pcf driver.
2017-06-03 wl [cff, truetype] Integer overflows.
2017-06-03 wl ftcalc.h: Avoid left-shift of negative numbers.
2017-06-02 wl [cff] Even more integer overflows.
2017-06-02 wl [cff] More integer overflows.
2017-06-02 wl [bdf] Don't left-shift negative numbers.
2017-06-02 wl [bdf] Fix integer scanning routines.
2017-06-02 wl [cff] Fix integer overflows.
2017-06-01 wl [smooth] Some 32bit integer overflow run-time errors.
2017-06-01 wl Minor comment.
2017-06-01 wl * src/base/ftglyph.c (FT_Get_Glyph): Check `slot->advance'.
2017-06-01 wl [psaux] 32bit integer overflow tun-time errors (#46149).
2017-06-01 wl * src/truetype/ttinterp.c (TT_RunIns): Adjust loop counter again.
2017-05-31 wl [cff] 32bit integer overflow run-time errors 2/2 (#46149).
2017-05-30 wl [cff] 32bit integer overflow run-time errors 1/2 (#46149).
2017-05-30 wl [psaux] Correctly handle sequences of multiple number signs.
2017-05-29 wl [pcf] 32bit integer overflow run-time errors (#46149).
2017-05-29 wl Handle some integer overflow run-time errors (#46149, #48979).
2017-05-28 wl * include/freetype/internal/ftcalc.h (FLOAT_TO_FIXED): Remove.
2017-05-28 wl [cff] s/cf2_floatToFixed/cf2_doubleToFixed/.
2017-05-28 wl Fix negation of INT_MIN and LONG_MIN (#46149).
2017-05-27 wl [truetype] Fix handling of design coordinates (#51127).
2017-05-24 wl [bdf, pcf] Support ISO646.1991-IRV character encoding (aka ASCII).
2017-05-20 madigens [truetype] Always use interpreter v35 for B/W rendering (#51051).
2017-05-20 apodtele [smooth] Implement minimal dynamic padding for LCD filtering.
2017-05-17 wl [autofit] More code sorting.
2017-05-17 wl Code sorting.
2017-05-15 wl [sfnt] Return proper scaling values for SBIX bitmaps.
2017-05-15 wl [truetype] Fix error handling for embedded bitmaps.
2017-05-15 apodtele [autofit] Make autohint warping NORMAL option.
2017-05-14 wl Remove remnants of raster pool.

Created with:
  roll-dep src/third_party/freetype/src
R=bungeman@chromium.org, drott@chromium.org, michaelbai@chromium.org, wangxianzhu@chromium.org

Change-Id: I3e5740eab26f174b3281e623855814ebc711ba8e
Reviewed-on: https://chromium-review.googlesource.com/550379
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483453}

(cherry picked from commit 4d6320ef3dee4ac9f29055b6b9d75497ea67796f)
BUG= chromium:726631 

Change-Id: I989a89f5a29d8c69cc5f9ac81d4c15413e2da03a
Reviewed-on: https://chromium-review.googlesource.com/592292
Reviewed-by: Ben Wagner <bungeman@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#691}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/5bb2255a4efdc1284b9c8775c65c03f11c099627/DEPS
[modify] https://crrev.com/5bb2255a4efdc1284b9c8775c65c03f11c099627/third_party/WebKit/LayoutTests/platform/linux/fast/text/chromium-linux-fontconfig-renderstyle-expected.png
[modify] https://crrev.com/5bb2255a4efdc1284b9c8775c65c03f11c099627/third_party/freetype/README.chromium
[modify] https://crrev.com/5bb2255a4efdc1284b9c8775c65c03f11c099627/third_party/freetype/include/freetype-custom-config/ftoption.h
[add] https://crrev.com/5bb2255a4efdc1284b9c8775c65c03f11c099627/third_party/freetype/roll-freetype.sh

 Issue 750515  has been merged into this issue.

Same here on latest v60 stable for linux.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/defbf350f6afd46f15b963d60bd5bd2bca00dfd2

commit defbf350f6afd46f15b963d60bd5bd2bca00dfd2
Author: Ben Wagner <bungeman@chromium.org>
Date: Mon Jul 31 21:35:08 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/110624096f7dbe2e59a8fd877269f10a9c52eac0

commit 110624096f7dbe2e59a8fd877269f10a9c52eac0
Author: Ben Wagner <bungeman@chromium.org>
Date: Tue Aug 01 03:32:04 2017

Just to update, tested this on the latest M-60(60.0.3112.90, which should contain the fix) with the attached font.conf.

Rendering seems to have improved under Wrench menu,omnibox,settings page, accounts.google.com pages and is back to normal as on previous stable(59.0.3071.115).

Attaching the screenshots from (59.0.3071.115, 60.0.3112.78, 60.0.3112.90) and adding the verified label therefore.

Deleted: fonts.conf 562 bytes

fonts.conf 562 bytes Download

Deleted: 726631_59.0.3071.115.png 85.5 KB

	726631_59.0.3071.115.png 85.5 KB View Download

Deleted: 726631_60.0.3112.78_Actual.png 85.4 KB

	726631_60.0.3112.78_Actual.png 85.4 KB View Download

Deleted: 726631_60.0.3112.90.png 90.1 KB

	726631_60.0.3112.90.png 90.1 KB View Download

Still exists everywhere :( on Google Chrome Version 60.0.3112.90 on Linux Mint(like that matters).

I could be wrong, but I think (per https://chromium.googlesource.com/chromium/src/+log/60.0.3112.78..60.0.3112.90?pretty=fuller&n=10000) that 60.0.3112.90 includes the merge from #74 but not the merge from #75.

But... I think I'm still seeing the problem in a ToT build at r491526. With the same config I described in #54 and #56, I'm getting non-strongly-hinted text. Am I missing something in my build?

Deleted: snap-174200.png 35.7 KB

	snap-174200.png 35.7 KB View Download

After the latest update (60.0.3112.90) problem still exists everywhere on Ubuntu 16.04

Deleted: Schermata del 2017-08-03 08-20-00.png 603 bytes

	Schermata del 2017-08-03 08-20-00.png 603 bytes View Download

@Comment 78: You've caught me there, the actual build of Chrome 60.0.3112.90 contains both, but unfortunately due to the timing of when this was caught, Chromium 60.0.3112.90 does not. We're aware of this issue.

However, this change only affects aliased glyph rendering. This change fixes the issue seen from the setup in Comment #31 (and of course the original report). This change will not change anything about the setup in Comments #54 and #56, which would be a different issue. Chromium probably is asking FreeType for 'hintfull', but this is what the new FreeType does in the v40 hinter for this setting. If you want the old behavior, you'll still need FREETYPE_PROPERTIES set, because that's how FreeType is handling that. While Chromium is 'ahead of the curve' here, this is how FreeType works post 2.7.0.


@comment 79 (and probably 77): Unfortunately, I don't really have enough information to understand your issue. Is it possible that you have --ignore-gpu-blacklist or 'GPU rasterization' enabled in chrome://flags?

#79: That's unrelated and tracked by  issue 732341 .

#80: Got it, thanks! Having such a drastic rendering change seems unfortunate, but it sounds like there's not much we can do. I'll publicize FREETYPE_PROPERTIES="truetype:interpreter-version=35" when I see people ask about this.

@Comment 80:
You were right bunge..., after setting the "GPU rasterization" back to default (from enabled) all the font rendering issues are gone. It might be something connected to my how my system is setup - nvidia optimus. 

I don't remember anymore what was the initial reason for enabling GPU rendering so I think I can live without it.

Thanks for the info, you can find my original issue with more info merged here as duplicate up in the comment stack. 

@comment 80:
You were right! After disabling "GPU rasterization" font rendering issues are gone! Thanks!