Inconsistent font rendering
Reported by
idlike2d...@gmail.com,
Jun 28 2018
|
|||||||||||
Issue descriptionChrome 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
,
Jun 28 2018
More stuff rendering incorrectly.
,
Jun 28 2018
https://github.com/mesonbuild/meson/pull/3799/files Is the url for the latest screenshot
,
Jun 28 2018
,
Jun 28 2018
,
Jun 28 2018
Likely due to a font config change, what's your default system font?
,
Jun 29 2018
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.
,
Jun 29 2018
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
,
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
,
Jun 29 2018
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?
,
Jul 2
#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.
,
Jul 2
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
,
Jul 2
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.
,
Jul 2
#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).
,
Jul 2
#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?
,
Jul 2
#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.)
,
Jul 3
#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.
,
Jul 3
#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.
,
Jul 3
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.
,
Jul 9
Over to drott for triage as he's been working on font matching lately.
,
Jul 10
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.
,
Jul 10
#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.
,
Jul 11
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.
,
Jul 11
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.
,
Jul 11
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.
,
Jul 11
,
Jul 11
Re #24, the PDF blankness is handled in issue 862051 . CC thomasanderson@ for the FontConfig update.
,
Jul 11
This is a regression in fontconfig. I'll try to submit a fix upstream.
,
Jul 11
Thanks, Thomas, for the quick action and taking this on!
,
Jul 12
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 .
,
Jul 12
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.
,
Jul 16
Please submit the patch upstream. Thanks.
,
Jul 16
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 :)
,
Jul 16
Ok. Committed.
,
Jul 16
Thanks, that was fast! I'll roll the changes into Chromium.
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3ff47e60c5ce645973e57fc8dbe88b43d63edaf4 commit 3ff47e60c5ce645973e57fc8dbe88b43d63edaf4 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Jul 16 19:25:20 2018 Roll fontconfig to d1f48f11 Commits: https://chromium.googlesource.com/external/fontconfig/+log/6cc99d6a82ad67d2f5eac887b28bca13c0dfddde..d1f48f11d5dffa1d954a1b0abe44ce9e4bfc3709 BUG= 857511 TBR=dnicoara Change-Id: Ib3b499aa63d87c2886261ddcfbe692f24f7be59a Reviewed-on: https://chromium-review.googlesource.com/1138543 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#575380} [modify] https://crrev.com/3ff47e60c5ce645973e57fc8dbe88b43d63edaf4/DEPS [modify] https://crrev.com/3ff47e60c5ce645973e57fc8dbe88b43d63edaf4/third_party/fontconfig/README.chromium [modify] https://crrev.com/3ff47e60c5ce645973e57fc8dbe88b43d63edaf4/third_party/fontconfig/include/src/fcstdint.h
,
Jul 16
,
Jul 17
Thanks for fixing quickly.
,
Jul 17
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...!!
,
Jul 23
,
Jul 26
,
Jul 27
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by nerdki...@gmail.com
, Jun 28 2018337 KB
337 KB View Download