Created attachment 173505 [details] Screenshots illustrating the differences - Scaled up 5x for visibility SUMMARY I'm experiencing an issue with Plasma 6 on Wayland in scaled modes (anything other than 100%), and it only seems to impact plasma/Qt applications. To me, it looks like it's forcibly turning font hinting off ("hintnone" in fontconfig terms) rather than using the specified hinting (hintfull). When scaling is set to 100% (in Display Configuration), fonts are correctly rendered using the hinter configuration specified in fontconfig. When scaling is set to 150% or 200%, it appears to forcibly set "hintnone" or otherwise prevent hinting. Note that this is *not* blur due to scaling artifacts. This appears to be a problem with how freetype is being asked to hint the fonts when scaling isn't 100%. (i.e. freetype is being asked to not hint the fonts.) STEPS TO REPRODUCE 1. Set fontconfig configuration to leverage truetype hinting and hintfull (autohint=false, hintstyle=hintfull). 2. Set KDE fonts to something that leverages truetype full hinting such as "Segoe UI 9" or "Arial 9", or some font that looks different when hinted at all. 3. Set scaling to 100% in "Display Configuration", and log out and back in, examine the rendered fonts. 4. Set scaling to 150% in "Display Configuration", and log out and back in, examine the rendered fonts. 5. Compare. OBSERVED RESULT Fonts appear to not be hinted at anything other than 100%. EXPECTED RESULT Fonts should respect the fontconfig hinting configuration at all scales. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Fedora 40 KDE Plasma Version: 6.1.4-1.fc40 KDE Frameworks Version: 6.5.0-1.fc40 Qt Version: 6.7.2-6.fc40 ADDITIONAL INFORMATION See attachments for examples. Included are: - plasma 6 examples taken from the kwrite menubar (but same rendering is present everywhere in plasma) - forcibly unhinted examples (for confirmation that plasma isn't hinting fonts at all) - correct, properly hinted examples (what plasma *should* look like)
Additional notes: - This plasma/qt issue is not specific to wayland. I was able to reproduce it on a Plasma (X11) session when scaled at 150% and 200% too. It seems to originate in high DPI code rather than wayland or x11 specific code (although perhaps the same error is duplicated in both places). - Changing QT_SCALE_FACTOR_ROUNDING_POLICY does cause rendering differences, yet the font is still not hinted properly in any of the 5 cases. "Passthrough" is most natural looking. - Chrome / chromium-based apps and wine are not impacted. - GTK applications suffer from a similar (but certainly different in origin) hinting issue in wayland (at least) that is worked around by setting GDK_BACKEND=x11. When unset, the font shapes are bad, but are different than this plasma/qt issue. - Firefox and thunderbird also suffer from apparently the same issue as GTK applications (the shapes are bad in an identical way), and it is worked around by setting MOZ_ENABLE_WAYLAND=0.
Upon further consideration, this is likely a Qt bug, so I've created a ticket there: https://bugreports.qt.io/browse/QTBUG-128874
It is indeed a Qt bug; the question is if it's Bug 491015 (which is also a Qt bug) or a different one. Since you've already opened a Qt bug report, let's track it there. Bug 491015 is being actively investigated, so once that's fixed, it will be interesting to see if this issue goes away too.
My immediate impression from just looking at that "Steve" text specifically makes me think it is the same issue. One appears properly hinted (no upper or lower fringes on round characters like "e" "c" or "o", and one has fringes. The Kate "Settings" screenshot is trickier but essentially shows the same thing. My impression there is that the top of letter "S" just so happen to align to a pixel boundary naturally when unhinted just as hinted, but you can see a difference with the top of the "H" character there. And of course the most telling situation with unhinted glyphs is with the horizontal strokes, like on the "e".
*** This bug has been marked as a duplicate of bug 491015 ***