You are not logged in.
Hello,
I did a fresh install of Archlinux with KDE and have problems with fonts in some applications. Fonts in most applications look good (e.g. Dolphin, Firefox, etc.).
However, some(?) applications look terrible (e.g. KMail, Falkon Browser). What fonts or font settings are used here? What can I do to improve font appearance?
Offline
Please replace the oversized images w/ links to ideally not downscaled images.
It's kinda hard to tell from this but superficially looks like subpixel hinting (the LCD filter) but that could be an artifact of the scaling nd the fonts are actually aliased.
Is this plasma on wayland or X11 and does that make a difference?
Is it a HiDPI monitor?
Offline
Sorry, full resolution pics here:
https://ibb.co/6sycCx9
https://ibb.co/HPS9kvJ
https://ibb.co/9YL4mWZ
Yes, it's HiDPI monitor, resolution 5120x2160 pixel.
I made a default installation of plasma and kde. Afaik it defaults to wayland.
Offline
Dolphin (good): https://i.ibb.co/WKwzNfV/Screenshot-20240425-081716.png
Falkon: https://i.ibb.co/2M9pf2b/Screenshot-20240425-081652.png
KMail (I guess): https://i.ibb.co/kcGVCfb/Screenshot-20240425-081627.png
Both bad images look like they're the same font as dolphin, but upscaled.
https://wiki.archlinux.org/title/HiDPI#KDE_Plasma
https://wiki.archlinux.org/title/HiDPI#Qt_5
printenv
Offline
I'm somehow lost. So many different settings for Plasma, Wayland, Xwayland, Qt5, Qt6, etc.
I don't understand why KMail has different font rendering as Dolphin. Both are KDE (Qt) applications.
Following environment variables had no effect:
PLASMA_USE_QT_SCALING=1
QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_ENABLE_HIGHDPI_SCALING=1
Offline
I was more curious what parameters actually are set - the difference between kmail/falkon and dolphin (and probably many other processes) would likely be the use of QWebEngine
Offline
Here is my environment
[stefan@zotac ~]$ printenv
SHELL=/usr/bin/bash
SESSION_MANAGER=local/zotac:@/tmp/.ICE-unix/751,unix/zotac:/tmp/.ICE-unix/751
WINDOWID=3
COLORTERM=truecolor
XDG_CONFIG_DIRS=/home/stefan/.config/kdedefaults:/etc/xdg
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_MENU_PREFIX=plasma-
LANGUAGE=
SHELL_SESSION_ID=a52eb584ab024d3ca9fb09d6e23d0d31
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
DESKTOP_SESSION=plasma
GTK_RC_FILES=/etc/gtk/gtkrc:/home/stefan/.gtkrc:/home/stefan/.config/gtkrc
XDG_SEAT=seat0
PWD=/home/stefan
XDG_SESSION_DESKTOP=KDE
LOGNAME=stefan
XDG_SESSION_TYPE=wayland
SYSTEMD_EXEC_PID=804
XAUTHORITY=/run/user/1000/xauth_fvLnaE
MOTD_SHOWN=pam
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/stefan/.gtkrc-2.0:/home/stefan/.config/gtkrc-2.0
HOME=/home/stefan
LANG=de_DE.UTF-8
XDG_CURRENT_DESKTOP=KDE
KONSOLE_DBUS_SERVICE=:1.72
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service/memory.pressure
WAYLAND_DISPLAY=wayland-0
KONSOLE_DBUS_SESSION=/Sessions/1
PROFILEHOME=
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
INVOCATION_ID=cb8180fe4e6b4774bf65a91ea95e2df8
KONSOLE_VERSION=240202
MANAGERPID=575
KDE_SESSION_UID=1000
XKB_DEFAULT_LAYOUT=de
XDG_ACTIVATION_TOKEN=kwin-2
XDG_SESSION_CLASS=user
TERM=xterm-256color
USER=stefan
COLORFGBG=15;0
QT_WAYLAND_RECONNECT=1
KDE_SESSION_VERSION=6
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
DISPLAY=:1
SHLVL=1
XDG_VTNR=1
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
XKB_DEFAULT_VARIANT=deadgraveacute
QT_AUTO_SCREEN_SCALE_FACTOR=0
JOURNAL_STREAM=8:13423
KDE_FULL_SESSION=true
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
QT_ENABLE_HIGHDPI_SCALING=1
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
KDE_APPLICATIONS_AS_SCOPE=1
MAIL=/var/spool/mail/stefan
KONSOLE_DBUS_WINDOW=/Windows/1
_=/usr/bin/printenv
Offline
Did some more Google research and found something:
https://www.mail-archive.com/kde-bugs-d … 93492.html
https://bugs.kde.org/show_bug.cgi?id=482445
Seems like I am not the only one...
Root cause seems to be fractal scaling on wayland:
https://bugreports.qt.io/browse/QTBUG-113574
Last edited by bluesurfer (2024-04-25 18:26:34)
Offline
Does "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" fix work around it for you as well?
The root cause is Wayland being difficult.
Offline
Does "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" fix work around it for you as well?
Yes it does.
What bothers me more is that the bug was reported nearly 1 year ago and nobody seems to care...
Offline
The root cause is Wayland being difficult.
We get sent an intger scale for the the QScreen (wl_output)When fractional support was added, they also "fixed it" to send it to the window directly. The wayland QPA will therefore return a QWindow with a dpr of 1.5, on a QScreen with a dpr of 2.
… we don't have the information available to keep it the same.
I don't think it's that nobody cares - here's a rant that touches on a couple of things that are wrong with wayland
https://dudemanguy.github.io/blog/posts … -xorg.html
You're seeing one of the symptoms of that - fractional scaling was completely tacked on…
Offline
I don't think it's that nobody cares -
If fractal scaling does not work for nearly one year - nobody cares.
Offline
Well, you care. Go, fix it.
Except I'll once more point out that
… we don't have the information available to keep it the same.
Wayland is a half-baked mess. And fractional scaling has never "worked".
This is a protocol/legacy problem, not a "some capable coder needs to invest some brain power to address this bug" problem.
Background
The big and obvious mistake to point out is fractional scaling. For some reason unknown to me, the Wayland protocol only supports integer scale values. To be frank, this is asinine and everyone pays the price for it. As higher resolution displays became common, users naturally wanted to scale the display to fractional values (1.5 and so on). Because telling users "you can't do this" to something as basic as this was a non-starter, all compositors implement a hack with this. They tell clients to scale up to the next integer and then the compositor downscales it to the correct one. So in the case of 1.5x scaling, clients are sent a scale value of 3 so they paint at 3x the resolution. Then, the compositor scales that down by 2. This is just, to be frank, incredibly stupid and wasteful. Clients (such as mpv under heavier settings) unnecessarily tax the GPU and then the end result is worse anyway. With text rendering in particular, it's noticeably more blurry.
This was then addressed by tacking on the fractional scaling protocol, but hitting a heterogenous environment that might have been isolated from the context that actually sees the fractional scale (since the output doesn't know about this becasue it would violate the wl core protocol) and because everyone tried to deal with this for over a decade and resulting in
… we don't have the information available to keep it the same.
And it would be really great if the interoperability of issues with and design flaws of wayland ended there…
Does it help to bypass all the DPI awareness stuff/wayland and control the fractional scale yourself?
QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_ENABLE_HIGHDPI_SCALING=0 QT_SCALE_FACTOR=1.25 falkon
Offline
I found that QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor breaks LSP Client popups in Kate: https://bugs.kde.org/show_bug.cgi?id=487505
So beware and do not set it globally, as it is probably less tested rendering setup by application authors.
Offline