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

Issue 857511 link

Starred by 12 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

Inconsistent font rendering

Reported by idlike2d...@gmail.com, Jun 28 2018

Issue description

Chrome Version       : 69.0.3472.3
OS Version: Ubuntu 18.04
URLs (if applicable) : https://github.com/kentcdodds/dom-testing-library/issues/63
Other browsers tested: No
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari:
    Firefox:
    IE/Edge:

What steps will reproduce the problem?
1. Visit https://github.com/kentcdodds/dom-testing-library/issues/63


What is the expected result?

The text to be rendered correctly

What happens instead of that?

font-weight is inconsistent. It's mostly but bold but it should be regular.

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

Doesn't happen in every single github tab that I open. I am not really sure what's triggering it. It didn't happen in the previous build.

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3472.3 Safari/537.36



 
Screenshot from 2018-06-28 21-36-00.png
226 KB View Download

Comment 1 by nerdki...@gmail.com, Jun 28 2018

I can confirm this regression in font behavior. Here is a screenshot comparing Chrome v69.0.3472.3 (on the right) to Chrome v67.0.3396.99 (on the left). 
Screenshot from 2018-06-28 12-42-50.png
337 KB View Download
More stuff rendering incorrectly.
Screenshot from 2018-06-28 22-24-59.png
246 KB View Download
https://github.com/mesonbuild/meson/pull/3799/files Is the url for the latest screenshot
Labels: Needs-Triage-M69
Components: Blink>Fonts

Comment 6 by e...@chromium.org, Jun 28 2018

Cc: derat@chromium.org
Labels: Needs-Feedback
Likely due to a font config change, what's your default system font?
I only changed the font used for monospace. As I said earlier this is not happening consistently. It happens on somepages but not others. And it's not just fonts, as shown in my second screenshot.
Screenshot from 2018-06-29 11-58-20.png
78.6 KB View Download
Project Member

Comment 8 by sheriffbot@chromium.org, Jun 29 2018

Cc: e...@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

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

Comment 9 by aschu...@warp10.net, Jun 29 2018

For me the same font rendering problem occurs on many sites (not only github). It seems that font selection is completely screwed.

Attached a sample from slashdot. Left Chrome 69.0.3472.3 (Official Build) dev (64-bit), Right Chrome 67.0.3396.99 (Official Build) (64-bit).

Fonts have not been changed from the theme defaults, but advanced font settings look very different.

OS: Xubuntu 18.04 LTS, fully updated
Chrome-Screen-Fonts.png
646 KB View Download
Chrome-Screen-Fonts-Settings.png
148 KB View Download

Comment 10 by derat@chromium.org, Jun 29 2018

Cc: drott@chromium.org behdad@chromium.org
original report and #2: It looks like some words are using a lighter weight, specifically 'dom-testing-library' and 'to'. Looking at https://github.com/kentcdodds/dom-testing-library/issues/63, I don't see anything in the DOM to suggest that this should be rendered differently.\

#1: I don't see the same weight problem in this screenshot that's discussed above, but it looks like a different font is being used to render capital 'I' characters in the old and new windows. Maybe drott@ knows what could be causing this.

#9: The settings page screenshot seems interesting. I don't know what 'Custom' means in that context. What happens if you select actual font families there, e.g. Times New Roman, Arial, and Courier?
#10: I've tried using "Sans" as Standard and Sans-serif font, and "Serif" as Serif font. Both the github issue and slashdot still render with the font problems.
I wanted to open a new issue, but this _might_ be the same bug. What do you think?

Entire monospace fonts are not rendered as monospace anymore. Particularly, CodeMirror instances.

# What specific URL can reproduce the problem?

https://codemirror.net/demo/simplemode.html

# Steps to reproduce the problem:

1. Open a CodeMirror instance in new Chrome and old Chrome (or Firefox), for example the url above.

# What is the expected behavior?

See first screenshot: monospace1.png

# What went wrong?

See second screenshot: monospace2.png
monospace1.png
121 KB View Download
monospace2.png
114 KB View Download
Addendum:

The above (error) is on Ubuntu 16.04.3. The error is on Chrome Version 69.0.3472.3 (Official Build) dev (64-bit).
The below (correct) is same system with Chrome Version 67.0.3396.99 (Official Build) (64-bit).

This bug was introduced on the dev channel within the last week, because I'm updating Chrome weekly, and it worked before.
#12: On Ubuntu 18.04, same Chrome version as yours, the CodeMirror page seems to use a different monospace font and  the font seem to be lighter (see screenshot, 69.0.3472.3 on the left, 67.0.3396.99 on the right).

Chrome-Screen-Fonts-CodeMirror.png
316 KB View Download
#14: Your screenshots are both monospace. Looks (different but) workable to me. My buggy version _is not even monospaced_ and thus unusable for reading code.

Maybe I should open a new issue for this bug?
#11: "Sans" and "Serif" are likely just aliases, right? Do you get consistent rendering when you select actual font names? See the attached screenshot, which is what I see at chrome://settings/fonts when using a new profile on a ToT Linux Chrome build at r572007.

(Even if you select specific fonts here, Fontconfig may be configured to return different fonts instead.)
snap-144946.png
32.4 KB View Download
#16: selecting Liberation Sans and Liberation Serif result in better results. The github URL from #1 look normal, but slashdot article headers are still rendered in the wrong font. DOM inspection shows that is should be "Arial, sans-serif", but it still renders as the serif font (see screen shot).

Xubuntu does not have Arial, so I can't test that.
Chrome-Screen-Fonts-Selct.png
445 KB View Download
#16: After further investigation it seems that slashdot rendering issue come from different interpretation of what the font-family specification of "arial, serif" means.

It Chrome 67, it renders as the "Sans" font, in 69 it renders as the "Serif" font. Given that Arial is a sans font, I think that Chrome 67 is right and 69 gets it wrong.

So, something seems to have changed with the font selection between 69.0.3464.0 and 69.0.3472.3.

This might also explain the monospace issue in #12. When I compare the DOM under 67 and 69, I see that it has chosen different monospace fonts. I would except that for the reporter it has chosen a non monospace font.

Screenshot of 67 and 69 attached.
chrome-67.png
585 KB View Download
chrome-69.png
540 KB View Download
I'm not sure what changed in Chrome's fallback logic, but since Arial is a common font, I'd recommend explicitly configuring Fontconfig to tell it to return your preferred sans-serif font when Arial is requested. I can't provide specific help with that, but e.g. https://seasonofcode.com/posts/how-to-set-default-fonts-and-font-aliases-on-linux.html looks like a good starting point.
Owner: drott@chromium.org
Status: Assigned (was: Unconfirmed)
Over to drott for triage as he's been working on font matching lately.
Indeed, Chrome dev's text rendering is completely broken on Linux, as it's ignoring the system's fontconfig settings. I explicitely disable hinting on all of my systems and now, for some unfathomable reason, Chrome is rendering all fonts with full hinting and grayscale (not LCD, as I have defined) antialiasing. Tested on Ubuntu MATE 18.04 with Chrome dev 69.0.3486.0.
#21: Hinting isn't being discussed here. Please file a new bug with before and after screenshots, along with the relevant portion of your Fontconfig settings.
Today, 69.0.3486.0 arrived, font selection is still broken.

#22: I think what he sees in #21 is just another result of the broken font selection. In deed, his assertion that Chrome is ignoring the system's fontconfig settings could be the root cause for this issue.
69.0.3486.0 broke the PDF rending. In 69.0.3472.3 is was using the wrong the monospace font, now it is using none at all. Everything is blank.

Test URL: https://www.etsi.org/deliver/etsi_ts/129200_129299/129274/14.07.00_60/ts_129274v140700p.pdf

Screenshot of page 2 attached.
Chrome-69-PDF.png
4.4 KB View Download
I've bisected the font breakage down to:

> You are probably looking for a change made after 569797 (known good), but no later than 569802 (first known bad).
> CHANGELOG URL:
>  https://chromium.googlesource.com/chromium/src/+log/84f58fd64c2aa9cbe2d4f6b356fb8a5a695092ce..86a87223c0d628e55a66d2658838be3436b1e853

From that range, the update of fontconfig in https://chromium.googlesource.com/chromium/src/+/a0c1584a2fade0146b7cd3380abe42feda02ad7c looks like the most probable cause.

Cc: susan.boorgula@chromium.org
 Issue 862434  has been merged into this issue.
Cc: thomasanderson@chromium.org
Re #24, the PDF blankness is handled in  issue 862051 .

CC thomasanderson@ for the FontConfig update. 
Labels: -Pri-3 -Needs-Triage-M69 M-69 Pri-1
Owner: thomasanderson@chromium.org
Status: Started (was: Assigned)
This is a regression in fontconfig.  I'll try to submit a fix upstream.
Thanks, Thomas, for the quick action and taking this on!
Re #28, 

> This is a regression in fontconfig. 

Do you have more details on what you think the problem could be? 

There might also be an issue with retrieving rendering settings from FontConfig, compare  issue 862434 .
Yes, the issue was fontconfig not being able to read certain directories that were symlinks.  Here's my patch to fix the issue.  This bug and  bug 862434  almost certainly have the same cause/fix.
0001-Return-canonicalized-paths-from-FcConfigRealFilename.patch
3.6 KB Download
Please submit the patch upstream. Thanks.
behdad@: Unfortunately, I do not have write permissions in the fontconfig repo. I sent the patch to Akia but I think he's OOO since he hasn't responded yet.  But I would appreciate if you could land the patch for me :)
Ok. Committed.
Thanks, that was fast!  I'll roll the changes into Chromium.
Status: Fixed (was: Started)
Thanks for fixing quickly.
Labels: TE-Verified-69.0.3494.0 TE-Verified-M69
Verified the fix on and Ubuntu 17.10 using Chrome version #69.0.3494.0 as per the comment #26 (i.e., duped  Issue 862434 ).
Attaching screen shot for reference.
Observed that the fonts rendered properly.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version 69.0.3472.3.

Thanks...!!
857511 CL_Verification.png
1.7 MB View Download
Cc: viswa.karala@chromium.org
 Issue 865421  has been merged into this issue.
Cc: krajshree@chromium.org kojii@chromium.org
 Issue 859451  has been merged into this issue.
Cc: bsep@chromium.org swarnasree.mukkala@chromium.org
 Issue 867142  has been merged into this issue.

Sign in to add a comment