SUMMARY Hello, I find default fonts in Neon to be washed out, not clear. 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. STEPS TO REPRODUCE Create a symlink to /etc/fonts/conf.avail/10-sub-pixel-rgb.conf in /etc/fonts/conf.d/ OBSERVED RESULT Fonts are definitely more legible, crisp and enjoyable. EXPECTED RESULT I expect this setting to work by default, being enabled in fonts settings, either enabling it system-wide as i did, either per-user in fonts.conf. Thanks. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.65 Qt Version: 5.13.2
Could you attach screenshots showing the problem before you apply the fix, and how it looks like afterwards?
Nate, isn't this a Plasma issue? From the plasma side we should force sound settings one would suppose. Specifically the settings which are considered the "default" in the KCM, which seems to be rgb sub pixel rendering. So, setting it globally enabled on neon would only hide the bug that the KCM defaults do not reflect the default behavior of Plasma.
Created attachment 125085 [details] Screenshots before
Created attachment 125086 [details] Screenshots after
Hello Nathan, sorry, my mistake. Just attached the images. Thanks. PS: I noticed the same link is missing on Ubuntu 18.04 LTS too, but Gtk fonts are already good there. The link has improved the aspect of some Qt apps, like Rosa ImageWriter used to create the live Neon images.
Thanks, that's helpful. TO be clear, before you made this symlink, if you navigated to System Settings > Fonts, did it say "Sub-Pixel Rendering: [RGB]" despite not actually working?
(In reply to Nate Graham from comment #6) > Thanks, that's helpful. TO be clear, before you made this symlink, if you > navigated to System Settings > Fonts, did it say "Sub-Pixel Rendering: > [RGB]" despite not actually working? Yes, it is enabled by default to RGB but not actually working.
Everyone (with a low resolution screen, sadly) can verify this bug, even with a live system: start the live -> check RGB is enabled -> make the link -> see the difference.
So I guess this is a Plasma bug then, yeah. The KCM should reflect the current state of reality accurately.
I had to downgrade plasma-workspace to 5.17.4 because it was eye-hurting on 1920x1080 displays.
*** Bug 419135 has been marked as a duplicate of this bug. ***
*** Bug 415707 has been marked as a duplicate of this bug. ***
*** Bug 420232 has been marked as a duplicate of this bug. ***
*** Bug 415471 has been marked as a duplicate of this bug. ***
I can no longer reproduce this issue with the latest state of git master. Could I ask for testing from others aloso running compiled-from-source code, or using KDE Neon unstable or a git-master-following repo in their distro of choice?
(In reply to Nate Graham from comment #15) > I can no longer reproduce this issue with the latest state of git master. > Could I ask for testing from others aloso running compiled-from-source code, > or using KDE Neon unstable or a git-master-following repo in their distro of > choice? Hello Nate, i've just installed current neon unstable in a VM and taken a look at KCM fonts settings. I can't no longer see the "Apply" button enabled with no changes made, as per a bug report added to this one as duplicated, but the original bug regarding sub-pixel-rendering not applied is still there. I have attached some files. Fonts.conf is the local setting file and there is no trace of rgb sub-pixel rendering enabled into it, even if it is set in KCM. Two screenshots made with Kate, depicting text with rgb sub-pixel rendering enabled in KCM and no link in /etc/fonts/conf.d and one with the created link. The difference is noticeable, as you can see.
Created attachment 128198 [details] Local fonts settings.
Created attachment 128199 [details] Screenshots_unstable_before
Created attachment 128200 [details] Screenshots_unstable_after
I see. Thanks for the confirmation!
Hello Nate, i can give you a feedback on the other bugs added as duplicated of this. I've deleted the symlink to rgb-subpixel-rendering in /etc/fonts/conf.d, logout and login, so the situation is a clean Neon unstable with KDE 5.18.90. Bug 415471: Can't set sub-pixel rendering to None. Status: STILL PRESENT. Bug 420232: Unexpected confirmation window after switch from "Fonts" section. Status: FIXED FOR ME. Bug 419135: On the fonts settings page, the Apply button is enabled, even if there were no changes. Status: As previously said, FIXED FOR ME. Bug 415707: fedora31/plasma 5.17.4 subPixelRendering RGB not taken into account after logoff/login Status: STILL PRESENT. No need to logout/login, changes made to fonts rendering are rejected, dolphin never gets rgb as reported by user.
I can add a comment: fresh neon user-edition installation (20200514), first access in KCM fonts, we have the button Apply enabled and are being asked to Accept, Discard, Delete with no action done. This happens only the first time. Next accesses in KCM fonts are good: you do nothing, you are not being asked anything. News is, on the first access, if you Accept the settings, the file ~/.config/fontconfig/fonts.conf is created and it contains the setting: <edit name="rgba" mode="assign"> <const>rgb</const> that applies rgb-subpixel rendering without creating the global link. Screenshots have been added. So, now the settings actually reflect the machine status. Last problem left is creating the fonts.conf without forcing the user to Accept a request he has never done.
Created attachment 128755 [details] Screenshots before link on neon-user
Created attachment 128756 [details] Screenshots after link on neon-user
I forgot to mention that on first access to KCM fonts, if you do not Accept the settings, next times you are being asked to accept over and over, probably because file fonts.conf is not created. Once you accept, file is created, requests finish and accesses to KCM fonts are normal.
I suspect https://bugs.kde.org/show_bug.cgi?id=431197 is related to this bug. I'm now receiving similar symptoms with the same workaround (add a symlink), but my issues started months after this bug report.
The KCM currently never writes the RGB setting from what I can tell. Culprit is FontAASettingsStore which seems to never set m_subPixelChanged and thus never syncs it into the Config object for writing to disk. Which in the end means the setting is just never added to the user config. At a glance m_hintingChanged may have the same problem, not sure if there's a bug report about hinting possibly also not applying. @Nate? Both only apply if and only if the config replicated by https://bugs.kde.org/show_bug.cgi?id=432539 don't already contain the setting. IOW if the config file already has a value it will get updated, if it doesn't it never gets added to the file because of the bug in the SettingsStore.
There's another aspect of this problem. Adding a symlink to /etc/fonts/conf.d resolves sub-pixel rendering in general, but some parts of Plasma and KDE apps do not benefit from that setting. Affected parts are: 1. Okular's contents (not just some specific filetypes, anything, even txt files are grey-scale). Okular's UI elements are fine though. 2. Some parts of KInfoCenter: its Energy section has grey-scale buttons "Change Percentage" and "Energy Consumption", and below is affected graph's labels comprised of small blurry numbers.
Those would be different bugs that need filing separately against the apps. If fontconfig is set up correctly then certain apps not behaving accordingly is likely a problem with Qt or the app. You may be asking how to tell ^^ If this command > fc-match -v|grep -i rgba outputs the correct value then fontconfig is technically correctly configured. Correct values are: 1(rgb), 2(bgr), 3(vrgb), 4(vbgr)
Created attachment 135695 [details] Text file opened in Okular This is just a common text file opened in Okular, not even a PDF. On top: Okular's toolbar, rgb applied. On bottom: Okular document view, text is rendered with "50 shades of grey" lol.
Created attachment 135696 [details] KInfoCenter's "Energy" section On top: greyscaled blurry time marks that belong to battery discharge graph. On bottom: just a header of info text describing battery details.
Hi Harald, This is what I received in response to your cmd: rgba: 1(i)(w)
You need to file separate bugs for these things. They have nothing to do with this bug.
Yeah, bug reports are already in place, but anyway, I believe sharing these notes here as well is worthwhile since this bugreport is about the only setting in Plasma that (somehow) relates to the described effects, and that setting doesn't work neither system-wide (symlink needed) nor for apps I mentioned. All I hope for is that due to bigger audience someone would check/confirm, some would report a similar issue, and someone might even fix it eventually.
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/378
Git commit aa840a9d08d62d88487db4096b2e7a0e73c977d2 by Cyril Rossi. Committed on 17/03/2021 at 08:30. Pushed by crossi into branch 'master'. KCM Fonts .fonts.conf was not updated and enforce consistency through UI If some elements in .fonts.conf were deleted (default), they weren't updated anymore, and cause inconsistency between the value displayed in the KCM and what is actually applied. UI consistency : when the user uncheck enable AA, then the style is set to None instead of default value. M +42 -19 kcms/fonts/fontsaasettings.cpp M +2 -2 kcms/fonts/fontsaasettings.h https://invent.kde.org/plasma/plasma-workspace/commit/aa840a9d08d62d88487db4096b2e7a0e73c977d2
Thanks for that, Cyril! What more needs to be done to call this bug fixed?
Works in Plasma 5.22. Should this bug be closed, marked as duplicate of https://bugs.kde.org/show_bug.cgi?id=431197, or should that bug be marked as a duplicate of this?
(In reply to nyanpasu64 from comment #38) > Works in Plasma 5.22. Should this bug be closed, marked as duplicate of > https://bugs.kde.org/show_bug.cgi?id=431197, or should that bug be marked as > a duplicate of this? This bug is somehow changed, but still persists in some conditions. I've deleted the symbolic link that applies sub pixel rendering system wide. I can see that user specific settings are present in ~/.config/fontconfig/fonts.conf and correctly applied: tony@thinkpad-x230:~/.config/fontconfig$ cat fonts.conf | grep rgb <edit name="rgba" mode="assign"> <const>rgb</const> but NOT if file fonts.conf is missing. If i delete fonts.conf and open fonts kcm, fonts.conf doesn't get created; kcm still shows RGB set but it is *not* actually applied. Same situation after a system reboot. If i change some settings in fonts kcm, e.g. changing pixel rendering to none, then fonts.conf is created and settings are correctly applied. Changing again pixel rendering to rgb finally works. So, conclusions are: on KDE Neon when file font.conf is missing, such as on a freshly installed system, or if it is deleted, it should be recreated as soon as possible, either by copying a skeleton system file, either by reflecting system wide settings. In the last case, as rgb-subpixel rendering symlink is missing, it should be set to none in kcm, to reflect system state. For a new user, fonts kcm is in an inconsistent state, showing settings not actually applied, so bug is still present.
*** Bug 431197 has been marked as a duplicate of this bug. ***
Created attachment 139667 [details] Test using Plasma 5.22.1 showing full font hinting is not applied. 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)
"Hinting" affects whether characters are reshaped to fit the pixel grid, and does not affect color fringing. "Sub-pixel rendering" affects whether colors are used to represent sub-pixel detail. What is the value of "Sub-pixel rendering", and do colors appear when you set it to RGB (or alternatively set it to something else and back to RGB)?
Thanks for the clarification and explanation! RGB was enabled by default, so I did not change that. I will retest and change this to something else, and back to RGB.
Still a problem with fedora kde 35.
I also had a problem to set the RGB subpixel rendering in Debian 11 with KDE and I guess it's this bug when KDE Fonts Settings doesn't set the ```````"rgba" property in fonts.conf file. I fixed it by generating the file by the utility **qt5ct** which creates the correct config file. I described it here: https://unix.stackexchange.com/questions/690088/how-to-enable-rgb-subpixel-font-anti-aliasing-in-kde-plasma
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2140
Git commit 5dd8cc919f54bf28152a80e1fa6f3f649ea4e47a by Harald Sitter. Committed on 20/09/2022 at 09:10. Pushed by sitter into branch 'master'. fonts: honor & present system defaults previously we'd pretend that a missing value meant our "plasma-ish" defaults would apply but that is utterly false. when no hitting is set, no hinting is set. this can happen when the system default fontconfigs don't set up any hinting. M +5 -4 kcms/fonts/fontsaasettings.cpp https://invent.kde.org/plasma/plasma-workspace/commit/5dd8cc919f54bf28152a80e1fa6f3f649ea4e47a
Git commit 2539a5667418ee78330c2a79224196fb28a94494 by Harald Sitter. Committed on 20/09/2022 at 09:17. Pushed by sitter into branch 'Plasma/5.26'. fonts: honor & present system defaults previously we'd pretend that a missing value meant our "plasma-ish" defaults would apply but that is utterly false. when no hitting is set, no hinting is set. this can happen when the system default fontconfigs don't set up any hinting. (cherry picked from commit 5dd8cc919f54bf28152a80e1fa6f3f649ea4e47a) M +5 -4 kcms/fonts/fontsaasettings.cpp https://invent.kde.org/plasma/plasma-workspace/commit/2539a5667418ee78330c2a79224196fb28a94494
Git commit dc24b7c1c4e2c9dfb74090f716da029e44e209ff by Harald Sitter. Committed on 20/09/2022 at 09:17. Pushed by sitter into branch 'Plasma/5.24'. fonts: honor & present system defaults previously we'd pretend that a missing value meant our "plasma-ish" defaults would apply but that is utterly false. when no hitting is set, no hinting is set. this can happen when the system default fontconfigs don't set up any hinting. (cherry picked from commit 5dd8cc919f54bf28152a80e1fa6f3f649ea4e47a) M +5 -4 kcms/fonts/fontsaasettings.cpp https://invent.kde.org/plasma/plasma-workspace/commit/dc24b7c1c4e2c9dfb74090f716da029e44e209ff