https://bugs.kde.org/show_bug.cgi?id=431197
--- Comment #35 from nyanpasu64 <[email protected]> --- Decided to get to the bottom of this bug, so I spent a day doing some research. The latest KDE's plasma-workspace 5.21.5 (at least the Arch package) does *not* contain the bugfix patch to kcm_fonts (KDE's Fonts settings dialog) at https://invent.kde.org/plasma/plasma-workspace/-/commit/aa840a9d08d62d88487db4096b2e7a0e73c977d2. According to the GitLab branch/tag list, that commit is only present in 5.21.90 (a 5.22 beta tag) and the 5.22 branch. ---- An interesting observation is that pressing Apply in KDE's Fonts dialog writes an incomplete ~/.config/fontconfig/fonts.conf at first, which grows in fields as you toggle more settings and press Apply. For example, unchecking antialiasing will add a previously-absent <edit name="antialias" mode="assign"> section set to false, and checking antialiasing will change the section to true. Additionally, changing the options tends to cause XML attributes in fonts.conf to reorder (like randomly switching between <test compare="less_eq" name="weight"> and <test name="weight" compare="less_eq">). I suspect this is due to a hashmap with an unstable key order. I think it would make more sense to pick a canonical order for the attributes, either logical or sorted lexicographically, to avoid spurious changes to fonts.conf when the user didn't make changes to the section. ---- I did some testing on plasma-workspace 5.21.5, using gedit (GTK4) as a stand-in for GTK/GNOME apps, and Kate/KWrite (Qt 5) as a stand-in for Qt/KDE apps. I was wondering why on Arch, toggling subpixel rendering in KDE's Fonts dialog caused GTK apps to change between subpixel and non-subpixel rendering, but didn't affect KDE apps (they were stuck in grayscale). Turns out that GTK apps pull some of their settings from "X resources", if not set by fontconfig. You can view these X resources by running `xrdb -query -all` (optionally `| grep Xft`). There's a list of the relevant keys and values at https://wiki.archlinux.org/title/Font_configuration#Applications_without_fontconfig_support. As for what causes the bug's behavior... if you enable/disable antialiasing in KDE's Fonts dialog, it sets both xrdb's Xft.antialias and fonts.conf's antialias. However, xrdb is ignored by both GTK and KDE apps, since it's overriden by fonts.conf. My test setup: - Disable antialiasing in KDE's Fonts dialog. - Verify xrdb -query | grep Xft.antialias says 0. - Verify ~/.config/fontconfig/fonts.conf sets antialias to false. - echo 'Xft.antialias: 1' | xrdb -merge - - Verify xrdb -query | grep Xft.antialias says 1. - However, antialiasing is still off in both gedit and kate, because they look at fonts.conf and see false. If you switch subpixel rendering in KDE's Fonts dialog, it only sets xrdb's Xft.subpixel, not setting fonts.conf's rgba. Consequently, `fc-match -v` does not have a line containing `lcdfilter`. GTK falls back to xrdb's Xft.subpixel value, whereas KDE apps always render in grayscale with subpixel off. Strangely when KDE's Fonts dialog tries to load previous settings for you to edit, it thinks you set subpixel to RGB regardless if you last set it to None. Additionally, KDE's Fonts dialog has no way to pick a LCD filtering mode, and writes neither xrdb's Xft.lcdfilter nor fonts.conf's lcdfilter. When both lcdfilter properties are unset, KDE apps default to lcddefault, whereas GTK apps default to lcdlegacy (bad color fringing, but not quite lcdnone levels of awful). KDE apps ignore xrdb entirely, while GTK apps pick one of two conflicting settings from the 2 systems in a strange complex way, where lcdnone always wins over lcddefault/lcdlight, but between lcdlegacy and lcdlight/lcddefault (which I can't distinguish easily), whichever is specified in xrdb wins over whichever is specified in fonts.conf. ---- How does the bugfix change things? I built a custom plasma-workspace package with aa840a9d08d62d88487db4096b2e7a0e73c977d2 applied by hand. The resulting Fonts dialog properly writes a rgba entry to fonts.conf, fixing KDE apps failing to pick up RGB antialiasing and the Fonts dialog failing to pick up non-RGB modes. However, the Fonts dialog still writes neither xrdb's Xft.lcdfilter nor fonts.conf's lcdfilter, so the above bizarre GTK/Qt discrepancies continue on Linux distros which don't set a lcdfilter mode by default. For example, Arch doesn't; the standard workaround is to `ln -s /usr/share/fontconfig/conf.avail/11-lcdfilter-default.conf /etc/fonts/conf.d/` yourself. This sets fontconfig's lcdfilter value to lcddefault, unifying rendering in both GTK and KDE apps. Additionally, this causes `fc-match -v` to output a new line saying `lcdfilter: 1(i)(w)`. Is it the responsibility of KDE and not the distro to set a reasonable lcdfilter value? I don't know what GNOME writes to ~/.config/fontconfig/fonts.conf (in terms of rgba, lcdfilter, etc.). I think a reasonable policy is to set fonts.conf's lcdfilter to lcddefault, and xrdb's Xft.lcdfilter to lcddefault as well, to mimic how KDE currently sets both whenever you change antialiasing/subpixel/etc. Is it still necessary for KDE to write the current font settings to both a X resource and fontconfig settings in parallel? Does GNOME write to both? Are there apps still used today which rely on X resources to get font settings and can't read the fontconfig data? My fear is that GTK apps will malfunction in strange inconsistent indeterminate ways (since GNOME sometimes prioritizes X resources and sometimes fontconfig) if KDE only writes to fontconfig, but another app or GNOME's settings/daemons write conflicting settings to X resources. ---- Looking into the future, IDK whether X-resource-based configuration works or not for Wayland apps, and whether KDE or GNOME on Wayland properly set the X resources for XWayland X11 apps. Sidenote: even with KDE's fonts.conf enabling subpixel rendering, gnome-tweaks still thinks antialiasing is Standard, not Subpixel. -- You are receiving this mail because: You are watching all bug changes.
