| Summary: | You can not enable sub-pixel rendering other than vendor default because system settings will put a check mark in the box to block anti-aliasing and make fonts unreadable and you can remove check mark but gets placed back upon opening and close | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Josh Freeno <freefreeno81> |
| Component: | kcm_fonts | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | bhush94, fabian, finoderi, nate, pip.kde, unassigned-bugs, yaohan.chen |
| Priority: | NOR | ||
| Version: | 5.16.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=409518 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
This is how it locks itself after you enable font anti-aliasing
kdeglobals in 'broken' state This is how it locks itself after you enable sub-pixel rendering This both my fontconfig and kdeglobals while I am in broken state. From 5.16.2 thru 5.16.3 and after the Noto-font update 20190111-2 I still can not enable sub-pixel rendering other than vendor default because the check mark gets placed in the box to block aliasing KDE globals from 5.16.3 while not broken. The only thing that breaks the fonts in the sub-pixel rendering |
||
For me the bug occurs when I just open 'Fonts' in systemsettings. To reverse this beauty one need to choose 'Vendor Default' in 'Anti-Aliasing', hit 'Apply', close systemsetting, then return to 'Fonts' and choose anti-aliasing method they prefer. Sometimes you have to do it 4-5 times. Yes after further use it is the sub-pixel rendering doing this for sure and not the font anti-aliasing. When you choose RGB it blocks anti-aliasing from 0 to 99. There was a big update yesterday in Arch and I thought it might fix the problem but no it did not. Operating System: Arch Linux KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 Kernel Version: 5.1.16-arch1-1-ARCH So the bug is with the fonts but now I am sure it is the sub-pixel rendering doing this. I too hoped it would be fixed in 5.16.3 but nope. Fonts become screwed up because of that autochecking 0-99 pt range exclusion. I use Arch too BTW, but 5.1.16-zen1-1-zen kernel. Is this a KDE problem or an Arch problem is the next question ??? It has been long enough for a fix to come down the chain so I am hoping this is not KDE and it is Arch but usually Arch is pretty good about fixing stuff within a day to two days at most. I am not seeing anyone talk about this anywhere. I posted on the KDE Reddit site and a couple people have the same problem. I really think it is an Arch problem now so maybe we need to both report to Arch. If you will report to Arch and leave me the link here I will follow up.I wanted to edit my bug report but I don't see how to edit it at all. > I am not seeing anyone talk about this anywhere.
This issue was discussed in the #plasma IRC channel. If a developer comes up with a fix, this ticket will get updated.
If you're affected by this bug, please upload the content of ~/.config/fontconfig/fonts.conf for analysis. @Josh Freeno It's not Arch specific just because Arch devss don't temper with plasma, these packages are from upstream. The reason nobody talks about it is because most of the distro don't have that fresh plasma yet. And Neon users... don't file bug reports that much. Here is my font config. <?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <dir>~/.fonts</dir> <match target="font"> <edit name="hinting" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintslight</const> </edit> </match> <match target="font"> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> <match target="font"> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> </fontconfig> Sorry for typos. I reported this days ago before the new updates even came out so I really don't understand what the deal is. (In reply to Michael from comment #8) > Sorry for typos. Right now I am having to use without sub-pixel rendering at all and i make themes for KDE so my screenshots look real nice as you can imagine. I have tried back and forth as you said but with not luck. This font config file goes into home directory correct ???? (In reply to Michael from comment #7) > @Josh Freeno > It's not Arch specific just because Arch devss don't temper with plasma, > these packages are from upstream. It's not about Arch devs introducing bugs, it could be a bug with a specific fontconfig version in Arch as well, compile options, etc. > The reason nobody talks about it is > because most of the distro don't have that fresh plasma yet. On Tumbleweed I don't see this bug. There are some other weirdnesses though like the config file changing layout sometimes, but nothing like adding an exclusion range without clicking the checkbox. > Here is my font config. It does not appear broken. Can you upload a fonts.conf while it's "broken"? OK. I opened systemsettings, chose 'Fonts', closed systemsettings, open Dolphin and that's how list of files in ~ looks now - https://i.imgur.com/OcpvZqG.png fonts.conf <?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <dir>~/.fonts</dir> <match target="font"> <edit name="hinting" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintslight</const> </edit> </match> <match target="font"> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> <match target="font"> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <test qual="any" name="size" compare="more_eq"> <double>0</double> </test> <test qual="any" name="size" compare="less_eq"> <double>297</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> <match target="font"> <test qual="any" name="pixelsize" compare="more_eq"> <double>0</double> </test> <test qual="any" name="pixelsize" compare="less_eq"> <double>396</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> </fontconfig> Can you also upload ~/.config/kdegloabls? Created attachment 121468 [details]
kdeglobals in 'broken' state
Here it is.
Made some home porn about reproducing the bug and 'fixing' fonts anti-aliasing: https://mega.nz/#!eRthhKib!YiEvAeRZCmzwLQY5nKCfJpHsdjdG26DOP7jKCjbEsE8 Created attachment 121471 [details]
This is how it locks itself after you enable sub-pixel rendering
Here is my kdeglobals config after enabling sub-pixel rendering. Here is my info on OS.
Operating System: Arch Linux
KDE Plasma Version: 5.16.3
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0
Kernel Version: 5.2.0-arch2-1-ARCH
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 7.6 GiB of RAM
Created attachment 121472 [details]
This both my fontconfig and kdeglobals while I am in broken state.
I add the fontconfig to the kdegobals because it would not let me select two files for some reason. This my first bug report so sorry if I have made mistakes in the reports. I just wanted to help get the info out there.
Also I would like to add that when I select defaults in font settings it does not reset fonts to the correct settings. It sets them to wrong size and and to noto black. Created attachment 121504 [details]
From 5.16.2 thru 5.16.3 and after the Noto-font update 20190111-2 I still can not enable sub-pixel rendering other than vendor default because the check mark gets placed in the box to block aliasing
This started in 5.16.2 and continues into 5.16.3. I am gonna leave my kdeglobals and my fontconfig. The Noto fonts were updated to "20190111-2" but this did not help the matter either. Fonts work fine with vendor default selected for sub-pixel rendering but if I try RGB then minutes later my font-aliasing is blocked from 0 to 99 so fonts become completely unusable.
Created attachment 121505 [details]
KDE globals from 5.16.3 while not broken. The only thing that breaks the fonts in the sub-pixel rendering
kde globals while not broken.
"Vendor Default" has been removed in Plasma 5.17, and instead the actual config files are parsed and their settings displayed accordingly. Please test again once Plasma 5.17 is released--or now, if you want to compile Plasma from source (https://community.kde.org/Get_Involved/development#Plasma) or use KDE Neon Unstable edition (https://neon.kde.org/download) (In reply to Nate Graham from comment #21) > "Vendor Default" has been removed in Plasma 5.17, and instead the actual > config files are parsed and their settings displayed accordingly. Well, Plasma 5.16 is still supported and earlier versions did not have this bug. If the final conclusion really is that 5.16's kcm_fonts module is declared unsupported already, please close as WONTFIX instead of FIXED to mark it that way. > Please > test again once Plasma 5.17 is released--or now, if you want to compile > Plasma from source > (https://community.kde.org/Get_Involved/development#Plasma) or use KDE Neon > Unstable edition (https://neon.kde.org/download) Other options are available: https://community.kde.org/Plasma/Live_Images#Shipping_the_latest_code_from_Git Ah right, I always forget about Krypton, sorry about that. We can keep this open in case someone wants to investigate the issue and fix it for Plasma 5.16. Once 5.16.5 is released though, we'll have to close it since that's the last scheduled bugfix release, and it's not a problem in 5.17. Well I really don't understand now. Vendor default is the only thing saving me right now. Any other sub-pixel rendering is totally breaking fonts. I am now about to report another bug with KDE completely freezes 10 times a day and you can't do anything at all and I work on my PC so yea not very fun. Seems as if we are now using a BETA OS once again. *** This bug has been marked as a duplicate of bug 409518 *** |
Created attachment 121261 [details] This is how it locks itself after you enable font anti-aliasing SUMMARY In fonts section of system settings for two days in Arch Linux after the latest two batches of KDE updates I can not enable font anti-aliasing because when I do and close out system settings and open it again and then open Dolphin at the same time it automatically puts a check mark in the box for blocking anti-aliasing so therefore it makes fonts completely unusable. This happened and I thought I had a corrupt system so I spent the time to completely reinstall Arch yesterday and it happened again as soon as I turned font anti-aliasing on. I normally use fonts with enabled anti-aliasing and RGB sub-pixel rendering with slight hinting for best looking fonts but the way it is now I can't not enable any of that because when I do enable it then it automatically puts a check mark in box for blocking anti-aliasing and sets it from 1-99. You can go and remove check mark and it puts it back again upon opening a couple apps. One last thing I am not for sure Dolphin has anything to do it with I know if you open and close system settings with Dolphin open it may talke a couple times but this happens for sure. STEPS TO REPRODUCE 1. Enable font anti-aliasing with RGB sub-pixel rendering and slight hinting 2. Close settings and open Dolphin 3. Open System Settings at the same time as Dolphin and you may have to open system setting and dolphin several times but the fonts will become unreadable. OBSERVED RESULT Unreadable fonts EXPECTED RESULT Readable fonts SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Yes (available in About System) KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59 Qt Version: 5.13 ADDITIONAL INFORMATION I am on Arch Linux stable and this happened on clean install after I thought my system was corrupt I reinstalled. This is pretty serious bug.