LibreOffice Writer: Bad font rendering with anti-aliasing disabled (hinting enabled) in KDE system settings

Hello,

my desktop interface is KDE.

I have anti-aliasing disabled system-wide (for font sizes of 8-12 pt), because it is much easier on my eyes and easier to read.

But for some time now (it started months ago, back then with Manjaro and LO 7.4.5-1) the font rendering in LO Writer no longer works properly.

Here’s a before/after comparison picture to show what I mean:

First I saved myself by downgrading to LO Still 7.3.7-3 and then setting the update lock.
Later, after reinstalling the system (switching to EndeavorOS), I installed LO Flatpak, which until a few days ago still displayed the fonts correctly.
But with the Flatpak update from November 8th, 2023, LO was suddenly affected here too!
Interestingly, I had previously installed LO Flatpak version 7.6.2.1 and after the update it was still the same version.
What I found out is that a “runtime” was probably updated (but don’t ask me what that is!).
Here, too, a downgrade to the previous version and subsequent update blocking helped.
With Flatpak, the versions are assigned using so-called commit codes:

Commit code 1aa14038cbe7408fab115258b431132b7c0d1e9e257ba194c187a96df5e5be95 from 11/8/23 affected
Commit code 7a83544cc21d1380efb3eeeb9f10adb26d125bc8db4936e82312a96e357e9abf from 10/23/23 not affected.
Both as I said version 7.6.2.1!

The situation is similar with Appimage:
Up to version 7.3.x → correct font rendering
From version 7.4.x → bad font rendering

This was also tested in several virtual machines and on a laptop in addition to my main PC.
I have tested distributions so far (all of them only KDE!): Manjaro, EndeavorOS, CachyOS
So it seems that all Arch-based distros are affected.

However: I also tested Debian Testing and MX Linux (both KDE) with current LO appimages and the error does not appear there!

There is also a bug report in LibreOffice:
https://bugs.documentfoundation.org/show_bug.cgi?id=156200

There you can also read, for example, how to reproduce the bug, if someone wants to test it.
But as I see it, the bug has been set to “unconfirmed” for months now, so nothing seems to be happening.

Presumably because LO tells itself, that it can work under Linux KDE (see e.g. Debian Testing), so the error cannot be found in LO itself.

Since it would be very important to me, that this error is eliminated, I don’t want to leave any stone unturned.

Does anyone have another idea about this?

I could report this as a bug to Arch myself.

But it would be a bit suboptimal, if I of all people were to do that, since my understanding isn’t even far enough to even install an (“original”) Arch Linux.
So I haven’t tried it under a pure Arch Linux to see whether the error even occurs. But probably if it also occurs under the three arch based distributions mentioned above.
And there I could only complain about the LO fromthe official repositories, otherwise they could reply that they are not responsible for creating Flatpak and Appimage.
Although the easiest way to find out is with the Flatpak version. Because both times this is version 7.6.4.2 and there were only a few changes in the last update:

I could have posted this post under Applications, it just concerns LibreOffice in general, regardless of whether it is from the repos or as a Flatpak or Appimage.
(And forgive me for the possibly bad English translation, that was the Google translation!)

Side question, maybe someone knows this by chance:

Are there actually other desktop environments, apart from KDE, where you can deactivate anti-aliasing system-wide, i.e. somewhere in the system settings?

I ask, because I would then specifically install it in the VM to see to what extent the problem exists there.

PS: I just looked at the screenshot (font comparison before/after) again and realized that you can hardly see the differences!
Unfortunately, the image was apparently unfavorably reduced/compressed after upload, so that even if you click on the enlargement here, it no longer looks like the screenshot, that I saved on my PC.

Let’s see, maybe I can upload the picture somewhere else and then paste it here as a link…

PS again (since I can no longer change/add to my post above after a few minutes): If you enlarge the image, you have to click “original image” again at the bottom right under the image, then it will be displayed better !
But at least on my PC I almost can’t see this link “original image”! There are two links, on the right under the image: once “download” and next to it “original image”, both in a faint, barely readable purple.

Maybe try Gnome?

There are options on Tweak the font anti aliasing, since it’s been a long time since I use LibreOffice (I rely on online version of Office365), I have never encountered this issue before.

1 Like

Yes, just tried it in Gnome… and yes, the problem exists there too!
Of course, the whole system doesn’t look that good without anti-aliasing because the default font is not designed for it (similar to KDE). So if you really want to use this sensibly, I recommend changing the system font to a more suitable one (I imported Verdana for this).

I just quickly installed the current LO version (7.5.8.2, Still) via the repos → affected
Then the cross-check with an old Appimage version (7.3.x) → not affected
Countercheck, Appimage, version 7.4.03 and 7.6.2.1 → affected
So everything larger than 7.3.x is affected!

I didn’t test Flatpak there, but it will probably be the same as with the KDE versions.

So it’s not a KDE problem either!

Oh yes, Debian Testing is now also partially affected!

Here is another summary (concerning the KDE systems that have already been tested):

Currently I have been able to reproduce the problem on three different systems (main machine, laptop and newly set up virtual machine, all running with KDE systems, mostly Arch based like EndeavourOS, Manjaro, CachyOS and Debian Testing) as follows:

LO, official repositories:
Arch: Versions up to and including 7.3.7-3 → NOT affected; from 7.4.x → affected
Debian: Until the current version (and versions below) 7.4.7.2 → NOT affected

LO, Flatpak:
Arch: Versions up to and including 7.6.2.1, Commit Code 7a83544cc21d1380efb3eeeb9f10adb26d125bc8db4936e82312a96e357e9abf from October 23, 2023 → NOT affected;
Versions from and including 7.6.2.1 (there are two different buids of this version!), Commit Code 1aa14038cbe7408fab115258b431132b7c0d1e9e257ba194c187a96df5e5be95 from November 08, 2023 → affected
Debian: Ditto/Same

LO, Appimage:
Arch: Versions up to and including 7.3.7.2 → NOT affected; from 7.4.0.2 → affected
Debian: Until the current version 7.6.2.1 → NOT affected

With Debian, the problem currently only occurs when/after switching to the current Flatpak version 7.6.2.1 with build from November 8th, 2023.

So, it must somehow be the interaction of LO with a “Linux component”! One that is now included or activated in the current Flatpak version, but not yet in the same Appimage version. However, it can apparently also be contained in the operating system itself and then leads to poor font rendering in the Appimage version in Arch-based systems. Or perhaps this component is also activated in the Appimage version in Arch-based systems (so it is not included in the system after all), but not in Debian.
I don’t know! :confused: