Summary: | krdb throws away all previous settings if no specific font DPI value is given | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Adam Williamson <adamw> |
Component: | krdb | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jsedlak, kevin.kofler, mrmazda, nate, rdieter |
Priority: | NOR | ||
Version: | 5.3.2 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/85399471b2aad37e4524bde20b70fe2cb61354ba | Version Fixed In: | 5.23.1 |
Description
Adam Williamson
2015-07-09 00:37:37 UTC
It also looks like deleting Xft.dpi will no longer have the intended effect in upcoming GTK+ releases, unless we can get: https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f reverted. :-( Just for a bit of context, I started this epic yak shave by noticing that the Fedora installer rendered slightly differently on our GNOME live image from how it rendered on our KDE live image and our traditional installer images. The difference boiled down to being in the DPI and hintstyle settings. GNOME (via gnome-settings-daemon) has a default of 96dpi and hintstyle 'medium'; it does not try and calculate a 'correct' DPI. GTK+, however - before the commit KK mentioned - defaulted to a calculated DPI and hintstyle 'full'. Fedora ships an /etc/X11/Xresources which also specifies 96dpi and hintstyle 'medium', but because krdb intentionally throws away Xft.dpi (because of this bug it also throws away everything else, but the throwing away of Xft.dpi is really intended), anaconda running in KDE winds up using the GTK+ default, i.e. the calculated 'correct' DPI. KVM virtual machines (which I was using to test), I think, try to specify a display size in mm which will lead to a DPI as *close as possible* to 96, but don't quite make it precise. The upshot was that the DPI used by anaconda running in KDE in a VM at 1024x768 was very slightly higher than the DPI used by anaconda running in GNOME in a VM at 1024x768 (like, 96.09 vs. 96), which made it render upper-case letters one pixel taller, which messed up our openQA tests... After Matthias helped me figure out that's what was going on, he decided to make GTK+ follow the same defaults as GNOME, i.e. just unconditionally use 96dpi (well, with an integer scaling factor for hidpi displays) if no specific Xft.dpi value is set (and default to 'medium' hinting rather than 'full'). Hence the commit above. I can see why KDE might not agree with the change, though, as it may be difficult for KDE to make GTK+ apps running in KDE use the same DPI as Qt apps; presumably you'd need to explicitly set Xft.dpi to the calculated DPI, but I don't know how straightforward it would be to have krdb find that calculated value from whatever calculates it. One more note for the record - after writing comment #2 I found out that X is written to simply lie about the physical display size in order to cause things that calculate a resolution from it to get 96dpi in any case: https://bugs.freedesktop.org/show_bug.cgi?id=41115 https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/ the only cases where that won't happen is where the user explicitly specifies a DPI on the X command line, or where they specify a DisplaySize in their Xorg config. So in fact in most cases, Qt is kinda wasting its time doing the calculation anyway, as X.org has nerfed the numbers so it'll result in 96dpi (or *nearly* 96dpi - I couldn't quite figure out if Qt rounds the calculation or not. If it doesn't, it'll wind up with a bit more or less than 96dpi in many cases). In Plasma 5.19, I see: Xft.hinting: 1 Xft.hintstyle: hintslight ...in the output of `xrdb -query`. Is this still a problem for you with the latest Plasma version? Well, the code that wipes the whole rdb is still there: https://github.com/KDE/plasma-desktop/blame/master/kcms/krdb/krdb.cpp#L476 One thing has changed around it, though. This commit: https://github.com/KDE/plasma-desktop/commit/873cbc1da8f3f2b589f9f2722a4e15a8fcbfe4e5 adds default values for anti-aliasing, which I think are what you're seeing. I don't really think the problem is 'solved', though. Ah, ok. I notice that you set the ticket to ASSIGNED. Are you planning to work on this? no, sorry, I just figured that was the appropriate state to set it back to from NEEDINFO. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1119 Git commit d4dd7478893e9ac72b0c89772a086b213bb33292 by Alexander Volkov. Committed on 18/10/2021 at 10:21. Pushed by volkov into branch 'master'. krdb: Fix removal of Xft.dpi from Xresources 'xrdb -remove' can't remove a specific entry, it removes all entries only. So query all entries, remove "Xft.dpi" from them, and replace Xresources with the result. Related: bug 376406 M +28 -7 kcms/krdb/krdb.cpp https://invent.kde.org/plasma/plasma-workspace/commit/d4dd7478893e9ac72b0c89772a086b213bb33292 Git commit 85399471b2aad37e4524bde20b70fe2cb61354ba by Alexander Volkov. Committed on 18/10/2021 at 10:34. Pushed by volkov into branch 'Plasma/5.23'. krdb: Fix removal of Xft.dpi from Xresources 'xrdb -remove' can't remove a specific entry, it removes all entries only. So query all entries, remove "Xft.dpi" from them, and replace Xresources with the result. Related: bug 376406 (cherry picked from commit d4dd7478893e9ac72b0c89772a086b213bb33292) M +28 -7 kcms/krdb/krdb.cpp https://invent.kde.org/plasma/plasma-workspace/commit/85399471b2aad37e4524bde20b70fe2cb61354ba |