Created attachment 188260 [details]
Font rendering comparison-example, anti-aliasing disabled, hinting enabled, up to version 7.3.7.x and thereafter

Created attachment 188262 [details]
Manjaro-KDE system settings (anti-aliasing & hinting), option 1

This is just to illustrate the described system settings in "Steps to reproduce". It's a screenshot, when set option 1.

Created attachment 188264 [details]
LibreOffice-anit-aliasing-settings

Created attachment 188683 [details]
Screenshot on Debian testing, 100 % scaling

Created attachment 188684 [details]
Screenshot on Debian testing, 130 % scaling

I can't reproduce on Debian testing with the settings you describe.
Attachment 188683 [details] attachment 188684 [details] show what it looks like for me, the first one is with a document zoom of 100%, the second one with 130%. No scaling applied in KDE system settings.

In my eyes, with the settings you describe, it's still less nice than without those, but other apps don't look any better...

What do other (KDE/Qt and Gtk) apps look like for you? Do they behave as you'd expect/want?

Out of curiosity: Is there any specific reason why you have exactly those settings as specified applied?

Also, can you please paste the exact information from "Help" > "About LibreOffice"?

Does it look different/better when you set environment variable SAL_USE_VCLPLUGIN=gtk3 before you start LibreOffice?

Thank you for answering.

As I described:
"On a MX Linux KDE, which I installed myself testwise in the VM, with an Appimage version of LO (7.5.4-2) running there, I could not reproduce the problem."
It's also a Debian based Distro.

But I have also tested EndeavourOS and CachyOS alongside Manjaro and there the same issue shows up.
So you can say that the problem occurs with probably all Archlinux (KDE) based distributions, if you apply it as described by me above (Steps to reproduce).

You asked:
"What do other (KDE/Qt and Gtk) apps look like for you? Do they behave as you'd expect/want?"
Yes, they do. At least in most cases! E.g. in the Manjaro system settings the font looks nice and evenly slim and smooth. Or even in Firefox (where I also have Verdana selected as the default font).
In Thunderbird, however, the font of incoming emails looks similarly "tattered". But not the subjects, just the actual email text .
Strangely enough, email text that I write then looks as expected again.

You asked:
"Is there any specific reason why you have exactly those settings as specified applied?"
Well, because with exactly these settings I get the slim and to me sharp looking font shown in the screenshots above (of course I mean the font as it looked BEFORE the LibreOffice update!).

Fonts with anti-aliasing enabled look bold and blurry to me. Readability is more difficult and tiring for me.

You asked:
"Also, can you please paste the exact information from "Help" > "About LibreOffice"?"
You mean from a version after the update, with the bad font rendering now?
Attached is a screenshot of a LO version in VirtualBox. (On my main PC I am currently using the current Flatpak version, where the problem fortunately does not (yet) exist. However, the Flatpak version has some disadvantages, so I would rather use the version from the official repositories, but to explain that would be offtopic here).

You asked:
"Does it look different/better when you set environment variable SAL_USE_VCLPLUGIN=gtk3 before you start LibreOffice?"
Um, I just tried that ... there's still an "export" on the front, so like that:

#export SAL_USE_VCLPLUGIN=gtk3

So I took away the # and saved it, then to be on the safe side I did a system restart and then restarted LO - unfortunately without improvement!

Created attachment 188685 [details]
LO-information-help-about

Thanks for all additional information.

(In reply to kde-user from comment #8)
> You asked:
> "Also, can you please paste the exact information from "Help" > "About
> LibreOffice"?"
> You mean from a version after the update, with the bad font rendering now?
> Attached is a screenshot of a LO version in VirtualBox. (On my main PC I am
> currently using the current Flatpak version, where the problem fortunately
> does not (yet) exist.

Yes, attachment 188685 [details] is exactly the information I was asking for, thanks.

> 
> You asked:
> "Does it look different/better when you set environment variable
> SAL_USE_VCLPLUGIN=gtk3 before you start LibreOffice?"
> Um, I just tried that ... there's still an "export" on the front, so like
> that:
> 
> #export SAL_USE_VCLPLUGIN=gtk3
> 
> So I took away the # and saved it, then to be on the safe side I did a
> system restart and then restarted LO - unfortunately without improvement!

Just to double-check: Does "Help" > "About LibreOffice" say "VCL: gtk3" instead of "VCL: kf5(cairo+xcb)" if you do that?

Since this issue only occurs in a specific setup and is not easily reproducible, you could increase chances of somebody being able to look into it by doing a bibisect, to identify at which change the behavior changed. More details here:
https://wiki.documentfoundation.org/QA/Bibisect/Linux

This is indeed strange ... although I have commented out everything again in the meantime (i.e. there is a # in front of it everywhere), it now looks different under Help -> About than it did before.
I post a screenshot below.
But even currently, if GTK3 is there, nothing changes in the font rendering.

Speaking of the font rendering, perhaps I should briefly mention this again: In practice, I use it as described in point 3.2 (Steps to reproduce). That is, only fonts from 8 - 15 pt are excluded from anti-aliasing. For larger fonts I see the advantage of anti-aliasing, it looks smoother then. But small fonts, as they are typically used in LibreOffice (around 10 - 12 pt) and with a zoom factor of around 100% in the view do not benefit from anti-aliasing in my opinion, but look bold and therefore somehow blurrier.

I'll read up on the thing with the "bibisect". But I have honestly never heard of it and my English is unfortunately not so special, so that will be a bit exhausting and time-consuming for me.

Created attachment 188691 [details]
LO information help about (shown GTK3)

Again for differentiation: The font rendering in LO is not bad everywhere. In the LO menu or popup windows it looks good, only in the page text itself there is bad font rendering.

Below I have added another screenshot and outlined what I mean.
The screenshot is from another virtual machine with CachyOS and LO-Fresh (official repositories).

Created attachment 188693 [details]
another screenshot of font-rendering

(In reply to kde-user from comment #12)
> I'll read up on the thing with the "bibisect".

Great, thanks!

I'm removing this ticket from the kf5 metabug, since the last comments indicate it's unrelated to this (rendering is only bad in the doc, happens with gtk3 just the same).

I didn't quite understand what happened now.

But I gather from your reaction (as far as I understood it) that the case is somehow not being pursued any further here?

I've tried to fumble my way into this Bibisect thing, but that's (much too) technical for me!

I had the page translated into German via Google, but I still understand almost nothing about it, also because some terms are apparently so specific that the translator can't do anything with them and either doesn't translate them at all or translates them incorrectly.
This is all far beyond my capabilities!

Unfortunately, I have to drop out at this point, which then presumably means that the problem will no longer be pursued by anyone, let alone solved.
That's really a pitty.

(In reply to kde-user from comment #17)
> But I gather from your reaction (as far as I understood it) that the case is
> somehow not being pursued any further here?

That's not the case, "dropping from the kf5 metabug" just means that this is not considered a bug caused by one specific part of LibrOffice (the "kf5 VCL plugin"), but this still remains a valid bug report for LibreOffice.

The fact that the issue only occurs in a specific setup and is somewhat hard to reproduce for developers unfortunately makes it less likely that it will get acted upon soon, though. (Whereas e.g. a bibisect result pointing to a change causing the issue would increase that chance, since the developer that made the change that caused the issue would be identified and thus potentially feel somewhat "responsible".)

> I've tried to fumble my way into this Bibisect thing, but that's (much too)
> technical for me!
> 
> I had the page translated into German via Google, but I still understand
> almost nothing about it, also because some terms are apparently so specific
> that the translator can't do anything with them and either doesn't translate
> them at all or translates them incorrectly.
> This is all far beyond my capabilities!

That's fair, thanks for trying anyway! In case you still want to get more information or see how that can work in action, feel free to ask questions via any of the QA channels mentioned at https://wiki.documentfoundation.org/QA or join a live video session with Ilmari where I'm sure he would be willing to show how bibisecting works as well. dates are announced on the QA mailing list referred to under the aforementioned wiki page. If you want to ask anything in German, you can also write to me directly.

Addition:

Until now, the Flatpak version of LibreOffice was the only version left, that did NOT have the problem with bad font rendering, when anti-aliasing was disabled.
This has now changed with the update from November 8th, 2023 and the Flatpak version is also affected!

What I found out:
Flatpaks have so-called commit codes, that can be used to clearly identify a version.

The last NOT affected version was 7.6.2.1 from 10/23/23,
Commit code 7a83544cc21d1380efb3eeeb9f10adb26d125bc8db4936e82312a96e357e9abf

The version now affected is (strangely enough) also version 7.6.2.1 from November 8th, 2023,
Commit code 1aa14038cbe7408fab115258b431132b7c0d1e9e257ba194c187a96df5e5be95
The subject of this version says:
Replace use of "Calibri" and "Calibri Light" with "Noto Sans" (b6ecbefa)

But to what extent this is the only change from the previous version, and whether or what this change has to do with font rendering in LO Writer, I don't know.
But something must have changed in this version, because immediately when I downgrade to the previous version everything is fine again!

Nobody an idea?

(In reply to kde-user from comment #19)
> Addition:
> 
> Until now, the Flatpak version of LibreOffice was the only version left,
> that did NOT have the problem with bad font rendering, when anti-aliasing
> was disabled.
> This has now changed with the update from November 8th, 2023 and the Flatpak
> version is also affected!
> 
> What I found out:
> Flatpaks have so-called commit codes, that can be used to clearly identify a
> version.
> 
> The last NOT affected version was 7.6.2.1 from 10/23/23,
> Commit code 7a83544cc21d1380efb3eeeb9f10adb26d125bc8db4936e82312a96e357e9abf
> 
> The version now affected is (strangely enough) also version 7.6.2.1 from
> November 8th, 2023,
> Commit code 1aa14038cbe7408fab115258b431132b7c0d1e9e257ba194c187a96df5e5be95
> The subject of this version says:
> Replace use of "Calibri" and "Calibri Light" with "Noto Sans" (b6ecbefa)
> 
> But to what extent this is the only change from the previous version, and
> whether or what this change has to do with font rendering in LO Writer, I
> don't know.
> But something must have changed in this version, because immediately when I
> downgrade to the previous version everything is fine again!
> 
> Nobody an idea?

@Stephan: Any idea?

I suppose the mentioned

> > Replace use of "Calibri" and "Calibri Light" with "Noto Sans" (b6ecbefa)

is just the font replacement for unit tests, which should be unrelated.

Not having much experience with Flatpak, one thought that came to my mind:
Besides changes to LibreOffice itself, could this possibly also be related to some change in Flatpak/the sandboxing mechanism, e.g. if some portal now makes font settings available for the Flatpak app as well that were previously ignored there?

From a quick glance at the changes, there seems to have been a runtime update [1] which may or may not be relevant if something like this is possible.

[1] https://github.com/flathub/org.libreoffice.LibreOffice/pull/264

(In reply to kde-user from comment #19)
> The last NOT affected version was 7.6.2.1 from 10/23/23,
> Commit code 7a83544cc21d1380efb3eeeb9f10adb26d125bc8db4936e82312a96e357e9abf
> 
> The version now affected is (strangely enough) also version 7.6.2.1 from
> November 8th, 2023,
> Commit code 1aa14038cbe7408fab115258b431132b7c0d1e9e257ba194c187a96df5e5be95
> The subject of this version says:
> Replace use of "Calibri" and "Calibri Light" with "Noto Sans" (b6ecbefa)
> 
> But to what extent this is the only change from the previous version, and
> whether or what this change has to do with font rendering in LO Writer, I
> don't know.
> But something must have changed in this version, because immediately when I
> downgrade to the previous version everything is fine again!

The latest version of the LO 7.6.2.1 flatpak released on 2023-11-08 is based on <https://github.com/flathub/org.libreoffice.LibreOffice/commit/b6ecbefa897f630e50a73f20605cde66890bffa0> "Merge pull request #264 from flathub/runtime-23.08" and uses the updated runtime org.freedesktop.Platform//23.08, rather than org.freeedesktop.Platform//22.08 as used by the previous version.

[This part in the angular bracket was updated on November 18, 2023:

Currently I have been able to reproduce the problem on three different systems (main machine, laptop and newly set up virtual machine, all runing 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: Dito/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]

The problem is caused by libcairo:
https://gitlab.freedesktop.org/cairo/cairo/-/issues/809

see also:
https://bugs.documentfoundation.org/show_bug.cgi?id=158366