Konsole font rendering regression.

selendym · 2019-12-30 22:05:18

Konsole version 19.08.1 (correct): https://i.imgur.com/hoYQPgM.png
Konsole version 19.08.2 (incorrect): https://i.imgur.com/eLUQEKr.png

It seems that starting with version 19.08.2, konsole renders fonts incorrectly.
The change is slight but most notably some characters seem vertically compressed, resulting in blurriness with small font sizes when anti-aliasing is enabled (see the screenshots).

Note that the notion of 'incorrect' can be verified by comparing the rendering of the same font and size with that of another program that does render correctly, e.g., VSCode.

thebelial · 2019-12-31 00:07:22

That's a yuge difference. I know you mention things like VSCode render correctly but do you notice this in any other application? I'm curious because I had a similar issue on my previous install and I only noticed it in Konsole.

If it's happening elsewhere it could be a font config file.

selendym · 2019-12-31 00:35:29

No other application has caught my attention so far, so I'm guessing it's Konsole at fault here.

Rolling back only Konsole has fixed this issue for me for now, but a proper fix would of course be welcome (assuming that this is an actual issue, though).

Last edited by selendym (2019-12-31 00:37:30)

V1del · 2019-12-31 00:47:59

The changelog between these two version is quite manageable: https://kde.org/announcements/fulllog_a … #ulkonsole

I suspect the HiDPI fixes and font weight calculation adjustments to have an impact here. And it generally looks like these are quite intentional, though you might want to chime in in the linked bug reports.

Last edited by V1del (2019-12-31 00:49:35)

selendym · 2019-12-31 01:58:24

As the whole program, not only the terminal view, is affected, I'd hazard a guess that the culprit here is: https://cgit.kde.org/konsole.git/commit … d66b657d49

I'll have to test reverting this at some point to be sure, though.

edit:
Fixing this issue seems to be as easy as simply commenting out one line, namely line 90 in 'src/main.cpp':

      QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);

Last edited by selendym (2019-12-31 03:06:32)

Lone_Wolf · 2019-12-31 10:03:03

Do you have a high dpi screen ?

If unsure, grep xorg log file for dpi and post the output.

selendym · 2019-12-31 21:02:51

'Xorg.0.log' has:

[    91.790] (==) AMDGPU(0): DPI set to (96, 96)

and 'xrandr --query' gives:

DVI-D-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 708mm x 398mm

I don't think this is a high DPI screen (is it?) and have never used scaling (at least intentionally), so I'd guess DPI is quite irrelevant in this case, assuming pixel-per-pixel rendering.
The PPI of the screen is ~92, so perhaps this has some implications when scaling is forced.

Lone_Wolf · 2020-01-02 13:50:51

Your screen is definitely not a HighDPI screen then.

What I think happens is the AA_EnableHighDpiScaling should be false for your screen but somehow is set to true incorrectly.

The bug report linked from that commit https://bugs.kde.org/373232 indicates locale settings (number settings) may play a role here.

please post ~/.config/kdeglobals and localectl output .

V1del · 2020-01-02 14:05:46

Also potential QT variables that might be exported, what's your output for printenv ?

selendym · 2020-01-03 03:19:11

'~/.config/kdeglobals' has:

[KShortcutsDialog Settings]
Dialog Size=779,1060

'localectl status' gives:

   System Locale: LANG=en_US.UTF-8
                  LC_TIME=en_DK.UTF-8
                  LC_COLLATE=C

Do note that the following line is unconditional and hard-coded into Konsole, as I noted above:

QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);

Commenting this out fixes the issue, but I assume a better approach would be for QT to verify whether the said option is to have any actual effect.

Also, my env doesn't seem to have any QT variables set; 'printenv' gives (after some pruning):

COLORFGBG=0;15
COLORTERM=truecolor
GTK_MODULES=canberra-gtk-module
GTK_OVERLAY_SCROLLING=1
KONSOLE_DBUS_SERVICE=:1.1154
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_VERSION=191200
TERM=xterm-256color
XDG_CURRENT_DESKTOP=X-Cinnamon
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_SESSION_TYPE=tty
XDG_VTNR=6

What I do have, though, is:

local/adwaita-qt 1.1.1-1
    A style to bend Qt applications to look like they belong into GNOME Shell

This is from AUR and may have something to do with this; I'll check this at some point.

Lone_Wolf · 2020-01-03 11:05:39

Try changing true to false in that line, if that works this is very likely a Konsole bug.

Sidenote

LC_TIME=en_DK.UTF-8

Are you from denmark or is that setting present to get thunderbird to display times in 24h format ?
If the latter, since thunderbird 56 there's a option that works for many people.
In preferences - general look for Date and Time Formatting .

digitalone · 2020-01-08 10:01:54

Same issue here. I downgraded and blacklisted the package. So, should I stay to 19.08.01 or is there something better I can do?

KDE devs seem very troublesome managing fonts: https://bugs.kde.org/show_bug.cgi?id=413133

digitalone · 2020-01-08 10:57:31

Solved with upstream version duplicating konsole desktop file in ~/.local/share/applications and changing exec lines with

exec=QT_AUTO_SCREEN_SCALE_FACTOR=0 konsole

digitalone · 2020-01-08 11:56:35

With the new update, KDE devs screw up fonts in all Qt apps. I noticed that the issue is not only related to konsole, but also dolphin, kate, akregator and other Qt applications.

If you don't want them to make other issues, create a script inside `~/.config/plasma-workspace/env/` and write:

#!/bin/bash

export QT_AUTO_SCREEN_SCALE_FACTOR=0

Restart and correct fonts will be shown.

kokoko3k · 2020-01-08 14:11:13

Thanks, good to know as soon as i'll update!

summerer · 2020-01-08 18:46:48

digitalone wrote:

With the new update, KDE devs screw up fonts in all Qt apps. I noticed that the issue is not only related to konsole, but also dolphin, kate, akregator and other Qt applications.
If you don't want them to make other issues, create a script inside `~/.config/plasma-workspace/env/` and write:
#!/bin/bash

export QT_AUTO_SCREEN_SCALE_FACTOR=0
Restart and correct fonts will be shown.

Thanks for the fix for yesterday's update!

digitalone · 2020-01-08 18:55:22

Don't mention it.

If you rely on a good system fontconfig, kde can screw up also that config locally. To prevent that, symlink `~/.config/fontconfig` to `/dev/null`.

Potomac · 2020-01-09 22:58:14

I have also these weird fonts rendering since the update of plasma packages,
my screen is a LCD monitor 16/9 1920x1080 pixels (24 inch monitor iiyama prolite XB2483HSU),

$ localectl
   System Locale: LANG=fr_FR.UTF-8
                  LC_COLLATE=C
       VC Keymap: fr-latin9
      X11 Layout: n/a

Not sure if kde developers are really aware about this bug and if they want to solve it,

the workaround I use is to export QT_AUTO_SCREEN_SCALE_FACTOR to 0, as explained by the other members of this forum.

And I put also my fontconfig file (fonts.conf) in /etc/xdg/kdeglobals file in order to preserve my fontconfig settings.

Last edited by Potomac (2020-01-09 23:00:40)

Trilby · 2020-01-09 23:51:41

Is your monitor actually 708mm x 398mm (measured with a ruler in meat-space)?

Even if it is, the 96x96 "default" is wrong, you DPI settings should be 92x92. Konsole now sets the scaling for HiDPI to true which should do nothing if your screen is not HiDPI ... of course it will do something (undesirable) if your screen's actually DPI is different from what the application is told.

Potomac · 2020-01-10 00:40:51

Trilby wrote:

Is your monitor actually 708mm x 398mm (measured with a ruler in meat-space)?

no, it's a standard 24 inch full HD 16/9 LCD monitor, with 1920x1080 pixels resolution

- dimension of the screen : 298.9 x 531.4 mm

- diagonal of the screen : 61 cm

- dimension of a pixel : 0.277 x 0.277 mm

https://iiyama.com/gb_en/products/prolite-xb2483hsu-b1/

perhaps it's a bug of Qt 5.14.0 related to HiDPI detection, as plasma relies on Qt5 functions ?
A simple "Hello world" Qt5 test program which would use HiDPI detection (a function which tells if the monitor has HiDPI) could confirm that.

There is an official documentation on Qt5 website for those who want to do more investigations :
https://doc.qt.io/qt-5/highdpi.html

The Qt::AA_EnableHighDpiScaling application attribute, introduced in Qt 5.6, enables automatic scaling based on the monitor's pixel density.

Last edited by Potomac (2020-01-10 00:54:11)

Trilby · 2020-01-10 01:26:47

I was asking about selendym's screen size, but yours also isn't 96x96 dpi, so if your settings specify that it is, this could be the problem.

The function in question isn't about assuming whether or not a screen is HiDPI, it's about whether Qt should treat every screen the same, or scale to fit the specified dpi. So if your settings have had incorrect DPI for a long time, this was harmless before, but now the wrongly specified DPI can have detremental results. Fix your DPI settings first.

https://wiki.archlinux.org/index.php/Fo … rted_fonts
https://wiki.archlinux.org/index.php/Xo … ze_and_DPI

Last edited by Trilby (2020-01-10 01:29:07)

Potomac · 2020-01-10 09:20:47

Trilby wrote:

So if your settings have had incorrect DPI for a long time, this was harmless before, but now the wrongly specified DPI can have detremental results. Fix your DPI settings first.
https://wiki.archlinux.org/index.php/Fo … rted_fonts
https://wiki.archlinux.org/index.php/Xo … ze_and_DPI

Ok but I never set manually the DPI (I don't have the need), I assume that the system should automatically guess the correct DPI value, according to the size and native resolution of the monitor ?

According to the wiki about Xorg :

To be able to set the DPI, the Xorg server attempts to auto-detect your monitor's physical screen size through the graphic card with DDC

A wrong DPI may mean a serious bug elsewhere in the system,

I will try these commands to see what is the current value of the DPI found by the system :

$ xdpyinfo | grep -B2 resolution
$ xdpyinfo | grep dots
$ xrdb -query | grep dpi

My graphic card is an old amd radeon HD4650 Pcie card, I use the radeon driver (official open source driver).

I suggest people here who has the same bug to check also what dpi value the system uses.

Last edited by Potomac (2020-01-10 09:35:48)

Lone_Wolf · 2020-01-10 11:30:01

The 96x96 DPI seems to be the the default used by Xorg to match other OSes .

See the links in the test box just under Display size and DPI heading at https://wiki.archlinux.org/index.php/Xo … ze_and_DPI
I found https://wiki.archlinux.org/index.php/Talk:Xorg (and the links in it) very interesting.

Potomac · 2020-01-10 12:15:01

The result of the commands :

$ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    1920x1080 pixels (508x285 millimeters)
  resolution:    96x96 dots per inch

$ xdpyinfo | grep dots
  resolution:    96x96 dots per inch

So the solution is not to modify the DPI, as the value 96 is the default for all OS, and most of softwares and fonts need a 96 DPI value for Xorg, in order to get a correct font rendering.

It is still not clear if plasma developers are really aware of this problem, and if they will revert the changes made in the last version of plasma related to HiDPI.

Trilby · 2020-01-10 12:18:04

Potomac wrote:

Ok but I never set manually the DPI (I don't have the need),

You didn't have the need because your software previously ignored DPI values - so even if it was wrong, it didn't matter. With HiDPI screens becoming more common, it will also become more common for software to adjust to whatever your DPI values are. Again, this is not some binary setting of HiDPI or not HiDPI, it's just that Konsole is now paying attention to DPI values where it used to ignore them. So if your DPI values have been wrong all along (which is very common!) then it would only now become more apparent.

The solution isn't to force Konsole to ignore false DPI values fed to it, but rather to correctly set up your DPI values.

Protomac wrote:

I assume that the system should automatically guess the correct DPI value, according to the size and native resolution of the monitor?

You assume wrongly.

And why assume at all when this is a trivial things to check. Get a ruler.

Protomac wrote:

I suggest people here who has the same bug to check also what dpi value the system uses.

More importantly, measure your actual DPI as I've been suggesting and you seem to still have not done. Checking what the system reports is secondary, as I'd bet that your systems will all report 96x96.

----

Potomac wrote:

So the solution is not to modify the DPI

Are you kidding?! Have you read anything I've posted. 96x96 is incorrect for your screen and I suspect this is why you are unhappy with the rendering. Just f(*&(ing fix your DPI first, then see if there is still a problem.

Last edited by Trilby (2020-01-10 12:33:05)

Arch Linux

#1 2019-12-30 22:05:18

Konsole font rendering regression.

#2 2019-12-31 00:07:22

Re: Konsole font rendering regression.

#3 2019-12-31 00:35:29

Re: Konsole font rendering regression.

#4 2019-12-31 00:47:59

Re: Konsole font rendering regression.

#5 2019-12-31 01:58:24

Re: Konsole font rendering regression.

#6 2019-12-31 10:03:03

Re: Konsole font rendering regression.

#7 2019-12-31 21:02:51

Re: Konsole font rendering regression.

#8 2020-01-02 13:50:51

Re: Konsole font rendering regression.

#9 2020-01-02 14:05:46

Re: Konsole font rendering regression.

#10 2020-01-03 03:19:11

Re: Konsole font rendering regression.

#11 2020-01-03 11:05:39

Re: Konsole font rendering regression.

#12 2020-01-08 10:01:54

Re: Konsole font rendering regression.

#13 2020-01-08 10:57:31

Re: Konsole font rendering regression.

#14 2020-01-08 11:56:35

Re: Konsole font rendering regression.

#15 2020-01-08 14:11:13

Re: Konsole font rendering regression.

#16 2020-01-08 18:46:48

Re: Konsole font rendering regression.

#17 2020-01-08 18:55:22

Re: Konsole font rendering regression.

#18 2020-01-09 22:58:14

Re: Konsole font rendering regression.

#19 2020-01-09 23:51:41

Re: Konsole font rendering regression.

#20 2020-01-10 00:40:51

Re: Konsole font rendering regression.

#21 2020-01-10 01:26:47

Re: Konsole font rendering regression.

#22 2020-01-10 09:20:47

Re: Konsole font rendering regression.

#23 2020-01-10 11:30:01

Re: Konsole font rendering regression.

#24 2020-01-10 12:15:01

Re: Konsole font rendering regression.

#25 2020-01-10 12:18:04

Re: Konsole font rendering regression.

Board footer