Description: Steps to Reproduce: When we upgraded from SuSE Linux Enterprise 15 SP5 to SP6 we realized the (same) version of libreoffice 24.8 showed worse font rendering in SP6 and our users complained it was more difficult to read texts. We had a service request with SuSE and they were able to reproduce it. Finally they advised me to open a bug report upstream because the SuSE support doesn't cover libreoffice at this level but someone from SuSE might be able to take a look here. Our findings so far: When upgrading from SP5 to SP6 the libcairo2 library has changed from 1.16.0 to 1.18.0. Libreoffice 24.8.0 (and newer, latest version I tried was 25.8.0.0) in combination with libcairo2 1.18.x (1.18.2 tested also) shows a different font rendering behavior such that the same letter is not always rendered the same way. With 1.16.0, every identical letter is rendered the same way (see old1.png), but with 1.18.x it changes every one or two letters (new1.png), depending on the font size. This causes a more noisy font face and makes texts harder to read at certain font sizes. It's especially annoying when letters could be rendered without anti-aliasing but get blurred due to this changing rendering, like in old3.png vs. new3.png (note: to get the very clear letters of old3.png I use "Xft.hintstyle: hintfull" in ~/.Xresources and SAL_ALLOW_DEFAULT_HINTING=true). I've already asked Caolán McNamara on the mailinglist and followed his advise to check the code part where there is a case distincion on the libcairo version, but this doesn't influence the problem. This might not be a sole problem of libcairo, however, because libreoffice 24.2.7.2 (and lower) shows the "same letter, same rendering" even with libcairo 1.18.x, i.e. it looks like in the "old" screenshots. I've compared the code in cairotextrender.cxx for 24.2.7.2 and 25.2.0.0 but couldn't find any difference that might explain that changed behaviour. As a first test I've fetched the different "tags" of libcairo from github. LO 24.8 has the "same letter, same rendering" up to libcairo2 1.17.2. It starts to show the "same letter, different rendering" starting with the next tag 1.17.4. This can easily be tested by just LD_PRELOADing the different libcairo.so files. LO 24.2.7.2 shows the "same letter, same rendering" with all versions up to 1.18.2. So it's not clear if this is a libreoffice or a libcairo problem. Maybe libcairo 1.17.4 introduced some new features that LO 24.8 is using while 24.2 did not yet? When SuSE was working at this SR they were able to reproduce the same problem also with Fedora 41 with LO 24.8.2.1 and libcairo2 1.18.0, so it's not SuSE-specific. I've found some other reports of changed/ugly font rendering with libcairo 1.17 which might be the same issue, although I'm not sure if 1.17.2+17+g52a7c79fd-1 mentioned in the last two reports is a pre- or post-release to 1.17.2. https://lists.cairographics.org/archives/cairo/2023-September/029500.html https://bugs.archlinux.org/task/64451 https://gitlab.freedesktop.org/poppler/poppler/-/issues/826 My report of this problem to the libcairo mailing list 4 weeks ago has got no reaction so far, unfortunately, so I'm not sure if the libcairo devs are interested in this issue. I will yet have to figure out how to commits to 1.17.2 one after another so that I might be able to find the exact commit that changed the behaviour. Maybe then it's easier to see what LO 24.8 is doing differently than to 24.2 w.r.t. that commit. Actual Results: Expected Results: Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.0.1 (X86_64) / LibreOffice Community Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab CPU threads: 8; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 198070 [details] 24.8 with different libcairo versions
Created attachment 198071 [details] new1.png
Created attachment 198072 [details] old1.png
Created attachment 198073 [details] new3.png
Created attachment 198074 [details] old3.png
A quick check of: git log 1.17.2..1.17.4 has a bunch of things, my guess is the difference in behaviour of version is likely to be one of (or more than one of) https://gitlab.freedesktop.org/cairo/cairo/-/commit/52a7c79fd4ff96bb5fac175f0199819b0f8c18fc https://gitlab.freedesktop.org/cairo/cairo/-/commit/e4a79db0108be6a2b06dfce51a44bcbdead66ebd https://gitlab.freedesktop.org/cairo/cairo/-/commit/ea9329215d3431ded51a71b724baf0edc25ad633 If you can build cairo from git, then $ git clone https://gitlab.freedesktop.org/cairo/cairo.git $ git checkout 1.17.2 built it, and if its good on LD_PRELOAD of the output of that version... $ git bisect good $ git checkout 1.17.4 and if its bad on LD_PRELOAD of the output of that version $ git bisect bad and git will keep picking commits for you to build to identify what was the triggering commit.
*** Bug 164292 has been marked as a duplicate of this bug. ***
(In reply to Gerald Pfeifer from comment #7) > *** Bug 164292 has been marked as a duplicate of this bug. *** Note that the reporter there also talked about using GNOME, not KDE as in an earlier report I have seen (before this got created).
I didn't state that so far, but at our chair we are using Gnome, KDE, Xfce and a bunch of old-style WMs, like mwm, ctwm, fvmw2 etc. and the effect is always there. So it does not depend on any desktop environment!
I have to point out: Libreoffice 24.2.1.2 + libcairo2-1.18.0 same letter ‘H’ is rendered same. Libreoffice 24.8.1.2 + libcairo2-1.18.0 same letter ‘H’ is rendered in different ways.
Thanks for pointing me to "git bisect", what a great feature! I was able to find the relevant patch: euler:~/libcairo/cairo> git bisect bad e4a79db0108be6a2b06dfce51a44bcbdead66ebd is the first bad commit commit e4a79db0108be6a2b06dfce51a44bcbdead66ebd Author: Matthias Clasen <mclasen@redhat.com> Date: Sat May 25 00:35:04 2019 +0000 xlib compositor: Support subpixel positioning As for the image compository, support a 4x4 subpixel grid. src/cairo-xlib-render-compositor.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) It's here: https://gitlab.freedesktop.org/cairo/cairo/-/commit/e4a79db0108be6a2b06dfce51a44bcbdead66ebd Does this shed some light why LO 24.2 and 24.8. behave differently? Or how this patch can cause same letters to be rendered in different ways? I'm adding Matthias to the CC list, maybe he can provide useful information.
Seems to be the same issue like https://bugs.documentfoundation.org/show_bug.cgi?id=156200 In my case, an older libcairo 1.16 helped: https://bugs.documentfoundation.org/show_bug.cgi?id=158366#c36 I don´t know, why libcairo's developer ignores this annoying bug. regards, Andy
Just to clarify - I'm using Linux Mint 22.1 and LO Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.1 Calc: CL threaded Bad rendering with libcairo 1.18. Good rendering with 1.16.
Well, in https://gitlab.freedesktop.org/cairo/cairo/-/issues/809 Emmanuele claims it's not a cairo issue but blames GTK and Pango. I'm not sure if this holds for the problem in this bug. When ldd the soffice.bin I don't see any gtk or pango library so I don't know if GTK is indeed involved. There is /usr/lib64/libreoffice/program/libvclplug_gtk3lo.so, however, but I've no idea what it does. Maybe Caolán can judge Emmanueles comment and tell if libreoffice uses GTK in a way that might cause this problem?
I´ve compiled libcairo 1.18.2 myself - and commented out some lines like described in https://gitlab.freedesktop.org/cairo/cairo/-/issues/809 So my code at cairo-xlib-render-compositor.c looks like (from line 1611 to 1619) /* unsigned long xphase, yphase; */ int this_x, this_y; int old_width; /* xphase = PHASE(glyphs[i].d.x); yphase = PHASE(glyphs[i].d.y); glyphs[i].index |= (xphase << 24) | (yphase << 26); */ I have fine rendering - non-antialiased and antialiase. So it IS a cairo issue?!? regards, Andy
Not neccessarily as e.g.libreoffice 24.2 works fine with libcairo 1.18. So it might indeed be the way the cairo features are used by other programs, like Emanuelle says. Maybe some components in libreoffice (or some other external library) have change between 24.2 and 24.8 so that they use other methods from cairo if those are available. Thus, it might be that on can make LO 24.8. work fine with libcairo 1.18 by telling it to use cairo the same way as 24.2 does. But if a 3rd-party lib is involved (like GTK) this might become difficult. But to analyze this, some better knowledge of the font code in LO neccessary, which exceeds my abilities. That's why I hope that Caolán might be able to help here. Another possibility would be to ask the cairo devs if they would accept a patch that disables the code you've removed (reverting Matthias' patch, who, unfortunately, doesn't seem to follow here; he might be able to explain what happens) by some environment variable. Maybe we should open a bug report pointing to this one here and ask about that, also considering the bunch of other similar reports.
LO 24.2 has same issue as 24.8 on my system. Only patched libcairo works fine with both.
Then you might not have the exact same issue as the one we discuss here, i.e. the different rendering of the same letter. See also comment 10. How do your HHHHH screenshots look like with 24.2 and 24.8.?
Created attachment 198664 [details] LO24.2 nonpatched antialiasing
Created attachment 198665 [details] LO24.2 nonpatched antialiasing 4x
Created attachment 198666 [details] LO24.2 nonpatched non-antialiasing
Created attachment 198667 [details] LO24.2 patched antialiasing
Created attachment 198668 [details] LO24.2 patched antialiasing 4x
Created attachment 198669 [details] LO24.2 patched non-antialiasing
I´ve uploaded some attachments - on my system even 24.2 has "your" issue ;-) Maybe SuSE upgrade changed libcairo, too? Ubuntu 22.04 had 1.16 in his repo.
Well, might be that the problematic effect doesn't happen in 24.2 with libcairo 1.18 for me because I use FREETYPE_PROPERTIES="truetype:interpreter-version=35", SAL_ALLOW_DEFAULT_HINTING=true and Xft.hintstyle: hintmedium. With these settings, fonts in LO 24.2. look the same no matter which libcairo version. Anyway, it's clear which patch in libcairo causes the problems, but I've node idea what this patch does and for what other features it is needed. Someone with more knowledge of the font code in LO might be able to tell. So far it remains unclear if something could be done in LO to avoid this problem, or if libcairo would need to be changed, e.g. with an environment variable or Xresource setting. But as my report on the libcairo mailing list was completely ignore, I'm not very optimistic about the latter...
Some detailed explanation - but sadly no solution: https://gitlab.freedesktop.org/cairo/cairo/-/issues/881
Very interesting: https://adamfontenot.com/post/improving_font_rendering_in_old_ui_toolkits_with_a_1_line_pango_patch The question is - how does LO use pango?
(In reply to andreas.franz from comment #27) > Some detailed explanation - but sadly no solution: > > https://gitlab.freedesktop.org/cairo/cairo/-/issues/881 According to Ulis explanation libcairo <= 1.17.2 rounded letter position to full integers (.0) while >=1.17.14 rounds to .0, .25, .50, .75, but it just works with the requested positions if gets from the next upper layer, e.g. pango. This causes more equal distance between letters but causes the negative effects with blurry letter we see. So, when I get it right: if a surrounding layer would round to full integers itself and pass those rounded positions to libcairo, then cairo would use the same positions as in 1.17.2 and earlier. Causing unequal distance between letters but sharper letters. So my question to Caolán: are those positions, that are sent to libcairo, created in libreoffice or in a mid-layer like pango? If it was possible to manipulate these positions in LO, then we might try to write a patch that (via a environment variable) might round those positions or not, so that one could switch between the "equal distance, more blurry" and the "unequal distance, less blurry" behaviour. Otherwise, if we know which layer between LO and cairo does this positioning, we can try to ask there...