Please note, I am using a HDPI LCD display with resolution of 3840x2160, and I can still see this issue with the fonts. Of course, on a non-HDPI display this issue is even more apparent. Thank you for the best clear demonstration of the issue. However I cannot reproduce it on openSUSE Tumbleweed; I get sub-pixel anti-aliasing with a 4K screen and a 200% scale factor. Text looks great. Seems like the anti-aliasing settings aren't being applied properly. Can you attach a screenshot of what the Fonts page in System Settings looks like for you? I also can't reproduce with a 1920x1080 monitor using xorg and using default font config on openSUSE. See my attachment. Created attachment 134612 [details]
opensuse 1920x1080
Created attachment 134627 [details]
Screenshot of font settings
Screenshot of Font Settings per request by @Nate Graham.
Can you try changing the hinting style from RGB to something else, then hit Apply, then change it back to RGB, then restart System Settings. At this point, do you see sub-pixel anti-aliasing in text in System Settings pages? (In reply to Carl Schwan from comment #4) > Created attachment 134612 [details] > opensuse 1920x1080 @Carl Schwan, Thanks for performing this test with openSUSE. I also checked out openSUSE, and I am getting the same result you are. I'll attach my screen shot as well, confirming what you saw. So @Nate Graham's suggestion that system font settings are not being applied in Neon (and perhaps Kubuntu?) may be a good track to pursue. Created attachment 134628 [details]
openSUSE Zoomed Screenshot with RGB and Full Hinting
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Created attachment 135106 [details]
Manjaro
This is how my font looks in Manjaro KDE 5.20.5, with RGB sub-pixel rendering and hinting set to full.
Created attachment "Manjaro". This is how my font looks in Manjaro KDE 5.20.5, with RGB sub-pixel rendering and hinting set to full. It seems the problem is reproducible in my fully upgraded Manjaro too. So far, it looks like Kubuntu, Neon, and Manjaro have this issue, but OpenSUSE doesn’t. Just tried neon-testing-20210122-1548 with Plasma 5.21. I've attached screen shots: 1. The new Kicker menu, zoomed in 2. The Font Settings with RGB and Full Hinting selected Created attachment 135136 [details]
The new Kicker menu in Plasma 5.21, zoomed in
Tested using neon-testing-20210122-1548.iso. Image shows the new Kicker menu in Plasma 5.21, zoomed in.
Created attachment 135137 [details]
The Font Settings with RGB and Full Hinting selected
Tested using neon-testing-20210122-1548.iso. Image shows the Font Settings with RGB and Full Hinting selected in Plasma 5.21.
This bug was the primary reason why I have abandoned the Neon distro just after I installed it. For me, font rendering is one of the most important visual properties of an OS. I believe this is also true for many others who spend most of their lives reading and writing a text on the computer. I wonder why the distro was released with a bug like this. Is it possible that none of the NEON testers noticed that? Created attachment 135314 [details]
Fringing in FF
Noticed this issue on Arch, but only in Firefox. In my case, it's probably a Firefox issue. Now the issue is gone. AA was enabled, RGB and slight hinting.
I can confirm this issue on Archlinux and Plasma 5.20.5. Qt apps running on Plasma have their text rendered using gray-scale (tested with Dolphin and VLC), while GTK3 apps (also running on Plasma) have their text rendered with RGB anti-aliasing (tested with Simple-scan). Marking as CONFIRMED due to multiple reports. Apparently something that openSUSE is doing suppresses this, since all other major distros are apparently affected. Can people who are affected paste the output of `fc-match -v`? Created attachment 135431 [details] Output of fc-match -v Output of fc-match -v per Nate Graham's request in comment # 20. Created attachment 135435 [details] Output of "fc-match -v" (unchanged under None vs. RGB) > Qt apps running on Plasma have their text rendered using gray-scale (tested with Dolphin and VLC), while GTK3 apps (also running on Plasma) have their text rendered with RGB anti-aliasing (tested with Simple-scan). I observed the same bug, with the added property that Firefox (and most likely GTK3 apps as well) doesn't turn on LCD filtering, resulting in prominent color fringes on vertical text edges. If I set KDE to grayscale antialiasing, both Qt and GTK apps (including Firefox) use grayscale properly. Clicking Apply in KDE's font settings writes to the file "~/.config/fontconfig/fonts.conf". Bafflingly, the file written is identical whether you pick None (grayscale) or RGB in the KDE settings. So I don't know how GTK even picks up a change in subpixel rendering. The output of "fc-match -v" is identical whether run from gnome-terminal or alacritty (didn't test Konsole), whether KDE is set to None or RGB (which changes the appearance of gnome-terminal). So I don't know why GNOME app rendering (including gnome-terminal) changes when I change KDE settings, when the fontconfig rules aren't changed. ---- I've encountered this issue on Arch Linux (unsure which Plasma version). I "fixed" the issue by adding a system-wide (or user-wide) fontconfig XML rule to manually set rgba to rgb and lcdfilter to lcddefault (https://wiki.archlinux.org/index.php/font_configuration#Pixel_alignment). Recently I switched to Garuda Linux (an Arch-based ricer distro with new and exciting bugs) and Plasma 5.20.5, and the bug is back. ---- I suspect https://bugs.kde.org/show_bug.cgi?id=416140 may be related to this bug. It describes similar symptoms, but was reported in 2020 January (months before I encountered a similar issue). And that bug report also has some commonalities with my experience written above: > Even if sub-pixel rendering is enabled, there's no trace of this setting in ~/.config/fontconfig/fonts.conf > If i create a symlink in /etc/fonts/conf.d to /etc/fonts/conf.avail/10-sub-pixel-rgb.conf, fonts improve a lot. Created attachment 135448 [details] Output of fc-match -v per Nate Graham's request in comment # 20. I can reproduce this with Kde Neon in virtualbox. Is this fixed with the commit above? Created attachment 137708 [details]
Still happening
Apparently not, as I can still reproduce the issue in today's Neon Unstable ISO (freshly downloaded). The combobox says RGB anti-aliasing, and it's not actually being used. See attached screenshot.
I just tested kubuntu-21.04-beta-desktop-amd64.iso
This seems to be working.
I've attached the following screenshots:
Test 1 - Default Slight Hinting with RGB (2021-04-19).png
Test 2 - Full Changed to Full Hinting with RGB (2021-04-19).png
In the first test, using default out-of-the box settings, you can see the colored fringes around the text. The settings were Slight Hinting with RGB.
In the second test, using updated settings with, you can see the also colored fringes around the text. Notice that the fringes have different darker colors around some of the characters. The settings were Full Hinting with RGB.
Created attachment 137718 [details]
Test 1 - Default Slight Hinting with RGB (2021-04-19).png
Test 1 - Default Slight Hinting with RGB (2021-04-19).png
Created attachment 137719 [details]
Test 2 - Full Changed to Full Hinting with RGB (2021-04-19).png
Test 2 - Full Changed to Full Hinting with RGB (2021-04-19)
I strongly suspect that this is related to the fontconfig shipped by the distro, which would explain why it could be working in Kubuntu but not Neon. @Nate, I can check the version or my package on Kubuntu. Which package should I look for ? (Also, I plan to to re-check my tests above to confirm that changing the setting from default —> full actually changes things. This is to confirm the “fringe” color changes in my two screen shots are because the settings actually changed, and not a side effect of taking screen shots at different positions in the screen. I may also test with a monitor that doesn’t have a HDPI screen, because it is easier to visually (subjectively) verify the font hunting/anti-aliasing). Just the plasma version. You can find it in the Info Center app. OS: Kubuntu 21.04 (beta) KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel version 5.11.0-16-generic Graphics Platform: X11 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. Correction: gedit is Version 40.1 on my system (from GNOME 40), but links to GTK3, not GTK4. Amazing research!
GTK apps use the gsettings back-end. I don't know if it supports reading from/writing to the native KDE files such as fonts.config.
In your test with Gedit, what happens if you set the following?...
gsettings set org.gnome.settings-daemon.plugins.xsettings antialiasing 'rgba'
gsettings set org.gnome.settings-daemon.plugins.xsettings hinting 'full'
Correction: > 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`. I meant to say "does not have a line containing `rgba`." This can be seen in the attachments to this bug (output of fc-match -v) (eg. https://bugs.kde.org/attachment.cgi?id=135435), where the `fc-match -v` outputs are missing `rgba` keys and corresponding values. However, my patched Fonts dialog writes a `rgba` value to fonts.conf, so now `fc-match -v` *does* have a `rgba` key. > GTK apps use the gsettings back-end. I don't know if it supports reading > from/writing to the native KDE files such as fonts.config. fonts.conf is not a KDE file, but a fontconfig file. It just happens to be generated by KDE, but is read by GTK apps, Qt apps, fed into freetype, etc. Does GNOME generate a fonts.conf file? According to the Arch wiki, https://wiki.archlinux.org/title/Font_configuration#Fontconfig_configuration says GNOME does, whereas https://wiki.archlinux.org/title/Font_configuration#Applications_not_picking_up_hinting_from_GNOME_settings says you have to edit your fonts.conf to specify hinting. These sources contradict each other, and I'd have to test a GNOME install to know for sure. > In your test with Gedit, what happens if you set the following?... > > gsettings set org.gnome.settings-daemon.plugins.xsettings antialiasing > 'rgba' > > gsettings set org.gnome.settings-daemon.plugins.xsettings hinting 'full' > gsettings set org.gnome.settings-daemon.plugins.xsettings antialiasing 'rgba' No such key “antialiasing” I think the new equivalent path is /org/gnome/desktop/interface/ in dconf-editor, and the key names are "font-antialiasing" and "font-hinting" (and "font-rgba-order" too, but I don't see any "font-lcdfilter"-ish key to pick a custom lcdfilter). Changing them does *not* affect how GTK3 apps look on KDE, with a fully specified fonts.conf. (I haven't tested how they interact with missing options in fonts.conf, or inconsistencies between fontconfig and X resources.) ---- The subpixel/RGB/None issues will be solved as soon as Plasma 5.22 gets released and reaches users (but requires users to reselect RGB/None to fix their fonts.conf). Maybe it's worth backporting to Plasma 5.21 (and possibly even earlier), since it fixes a broken configuration option, though I'm not sure if backporting will help it reach more LTS/fixed-release distributions or not. As to fixing the LCD filter, the hands-off approach is for KDE to to not set a LCD filter and let distros pick a default filter (or not pick any and make users figure out the resulting mess themselves). The easy solution is to set fonts.conf's lcdfilter to `lcddefault` if unset (and always set xrdb's Xft.lcdfilter to match fonts.conf), but allow users to edit fonts.conf in a text editor and set lcdfilter to another value. (The Fonts dialog currently preserves user-added/modified options in fonts.conf, so this behavior only has to be maintained.) If desired, the dialog GUI could be changed to allow picking a lcdfilter graphically (at the cost of surfacing more complexity to the user). It's a bad idea to force it to `lcddefault` unconditionally, because it's applied *after* ~/.config/fontconfig/conf.d/99-*.conf (making it impossible for users to override the lcdfilter in their own config files), and adding config files in ~/.fonts doesn't actually work in my testing. ---- Perhaps it's still worth testing how pure-GNOME installations handle fontconfig and X resources configuration, and testing KDE and/or GNOME on Wayland and/or XWayland. But I'd have to set up a VM or make a live USB (since I don't want KDE and GTK's user profile changes to collide with each other, unless you specifically want to test those messy interactions). I think this bug was resolved in Plasma 5.22. It's been weeks since Plasma 5.22 being released and nobody has closed this bug yet, so I'll do it even though I'm not bug staff. Can anyone who was experiencing it before confirm that it's fixed in 5.22? I was experiencing this issue before, and it has been fixed since 5.21.90 (including 5.22). I’ll try to check as well, but I won’t be able to get to it today. For the record, to fix this issue after you've upgraded to Plasma 5.22+: - Open the Fonts settings panel. - Switch "Sub-pixel rendering" from RGB to another value, and press Apply. - If desired, switch it back to RGB and press Apply again. Also should this bug be marked as duplicate of https://bugs.kde.org/show_bug.cgi?id=416140, should that bug be marked as a duplicate of this, or neither? There's a report at https://bugs.kde.org/show_bug.cgi?id=416140#c39 that this bug isn't 100% fixed (~/.config/fontconfig/fonts.conf isn't created by default if absent, only when the user *changes* their font settings). I suppose we should discuss there instead. *** This bug has been marked as a duplicate of bug 416140 *** I don't see a difference. See the attached image showing the results of three different tests using neon-user-20210617-0945.iso with Plasma 5.22.1: 1. The default settings 2. After setting Full hinting 3. After installing and setting Roboto fonts (package fonts-roboto-fontface); Full hinting is still active from test #2. Anti-aliasing is enabled by default for all tests. Notice that all three tests do not have the colored fringes around the fonts. (See attached file: Comparison Slight and Full Hinting in Plasma 5.22.1 (2021-06-25).jpg) Created attachment 139666 [details]
Test using Plasma 5.22.1 showing that this bug has not been fixed.
After setting full hinting and after installing and setting a different font, this bug still persists.
In addition to the last comments, the (only) ways to enable/apply sub-pixel anti-aliasing is either by cycling through sub-pixel rendering options RGB->None->RGB (with pressing Apply after each step) or by disabling and then enabling Anti-aliasing (again with Apply after each step). It cannot be applied by changing the Hinting options. I also confirm that sub-pixel anti-aliasing is not applied by default, although it is set in Fonts settings. The above behavior is observed with neon-developer-20210628-1846.iso image. It looks the issue is partially fixed. Still a problem with fedora kde 35. Can reproduce 100% on Fedora 36. This is the same issue as Bug 416140; marking as a duplicate. *** This bug has been marked as a duplicate of bug 416140 *** |
Created attachment 134595 [details] Screenshot demonstrating font rendering issue SUMMARY ------- Fonts in KDE are fuzzy. STEPS TO REPRODUCE ------------------ 1. Boot into KDE 2. Select Full hinting 3. Select RGB Anti-aliasing 4. Open a text editor and type text 5. Take a screenshot of the text 6. Open the screen shot in an mage editing application and zoom in (x1600). 7. Notice that the text was rendered using gray-scale (there are grey pixel "fringes" on the text). 8. Repeat steps 2-6 in a non-QT based DE (such as Gnome) 9. Notice the fonts are rendered using RGB anti-aliasing (there are colored pixel "fringes" on the text). OBSERVED RESULT --------------- Fonts in KDE are fuzzy. This is present in all applications and is especially noticeable for fonts rendered on colored backgrounds, such as used by Kicker. EXPECTED RESULT --------------- Subjectively, fonts should look sharp. Objectively, the fonts in step 7 above (zoomed in) should have colored pixel "fringes" demonstrating that anti-aliasing was applied correctly. SOFTWARE/OS VERSIONS -------------------- Windows: N/A macOS: N/A Linux/KDE Plasma: KDE Neon 5.20 (based on Ubuntu 20.04) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This issue occurs with other KDE based DEs as well (such as Kubuntu). I believe this may be an issue with the Qt framework and how it buffers text before rendering to the screen.