Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#68341 - [fontconfig/gnome-terminal] Very ugly subpixel rendering

Attached to Project: Arch Linux
Opened by Jakub (cartesius) - Monday, 19 October 2020, 22:18 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 April 2021, 10:54 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



Please see image but maybe non-reproducible by a simple screenshot.
Came from system with freetype **2.10.2**, same fontconfig settings (subpixel rgb, slight hinting), Gnome 3.36 to the freshly installed Arch system with Gnome 3.38 and JetBrains Mono white on black.

Font rendered in `gnome-terminal` looks very ugly at least on EIZO CG2420 professional LCD display. Classic colored "subpix artifacts" easily seen, much more intense, nothing like that occured in the previous setup with the same fontconfig settings.

It's no go for me for the "white on black" gnome-terminal. Haven't seen such strong artifacts in months.

Not sure if it's
1) Freetype 2.10.3 issue (Cleartype issue?)
2) Gnome 3.38 issue
3) gnome-terminal issue.

...but fonts in other apps (GTK) look OK. Moreover, gnome-terminal does offer only a tiny fraction of monospaced fonts currently installed on machine (community packages Roboto, Ubuntu... not seen) and only one or two variant of each font.

Additional info:
$ ls /etc/fonts/conf.d/
10-hinting-slight.conf 51-local.conf 69-urw-fallback-specifics.conf
10-scale-bitmap-fonts.conf 60-generic.conf 69-urw-gothic.conf
10-sub-pixel-rgb.conf 60-latin.conf 69-urw-nimbus-mono-ps.conf
11-lcdfilter-light.conf 65-fonts-persian.conf 69-urw-nimbus-roman.conf
20-unhint-small-vera.conf 65-nonlatin.conf 69-urw-nimbus-sans.conf
30-metric-aliases.conf 66-noto-mono.conf 69-urw-p052.conf
40-nonlatin.conf 66-noto-sans.conf 69-urw-standard-symbols-ps.conf
45-generic.conf 66-noto-serif.conf 69-urw-z003.conf
45-latin.conf 69-unifont.conf 70-no-bitmaps.conf
46-noto-mono.conf 69-urw-bookman.conf 80-delicious.conf
46-noto-sans.conf 69-urw-c059.conf 81-ubuntu.conf
46-noto-serif.conf 69-urw-d050000l.conf 90-synthetic.conf
49-sansserif.conf 69-urw-fallback-backwards.conf README
50-user.conf 69-urw-fallback-generics.conf
This task depends upon

Comment by Jakub (cartesius) - Monday, 19 October 2020, 22:21 GMT
Tried Guake as other terminal and same font rendered in Guake looks beautiful. When both windows next to each other, the discrepancy is extreme.
Comment by Jakub (cartesius) - Tuesday, 20 October 2020, 04:34 GMT
Well, sorry for another comment, but it definitely has something to do with monospaced font detection rather than font rendering itself.
If it's "broken" on the font side there should definitely be a workaround because from dozens monospaced fonts only a fraction is properly detected by GNOME Terminal 3.38.1
Comment by Jan Alexander Steffens (heftig) - Wednesday, 21 April 2021, 11:03 GMT

ln -st /etc/fonts/conf.d /usr/share/fontconfig/conf.avail/11-lcdfilter-light.conf
Comment by Jan Alexander Steffens (heftig) - Wednesday, 21 April 2021, 11:04 GMT
If -light is not soft enough, remove -light again try -default.
Comment by mattia (nTia89) - Sunday, 20 March 2022, 15:09 GMT
duplicate of #68566 ?