Description: Font aliasing looks like blurry again. This is recurrent issue showing up and down from time to time. Steps to Reproduce: 1. Text rendering looks blurry and not crispy clear 2. Using Georgia 13 pt (TrueType Font) 3. See sample images for bad and good font rendering 4. Using Debian 11 and XFCE Actual Results: Text rendering looks blurry and not crispy clear Expected Results: Text rendering looks fine and crispy clear Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 516f800f84b533db0082b1f39c19d1af40ab29c8 CPU threads: 2; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Created attachment 191034 [details] Bad font rendering
Created attachment 191035 [details] Good font rendering
No reproduced with 13 pt Georgia in: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Can you please test again with a recent trunk build and if you can still reproduce, provide an example file and the zoom level you see the issue at? https://dev-builds.libreoffice.org/daily/master/current.html Thank you!
Adding the requested info: 1. Tested with LO DEV: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 76400f66096a5cdc64cbd72ed9a94961b3200216 CPU threads: 2; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Results: Still experiencing a bad rendering. Zoom 100% → bad render (image 1) Zoom 280% → looks like the same render as LO 7.6 (good) (image2) 2. Tested with LO release (7.6) Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded Results: Good / nice rendering. Zoom 100% → good render (image 3) Zoom 280% → looks like the same render as LO Dev (image 4) (see images)
Created attachment 191390 [details] IMAGE 1
Created attachment 191391 [details] IMAGE 2
Created attachment 191392 [details] IMAGE 3
Created attachment 191393 [details] IMAGE 4
I'd like to add that LibreOffice 7.6.4 is a disaster of rendering. SKIA has been switched off but highlighting a text gives grey patches. It is not possible to produce a screenshot because such action corrects the problem temporary. ;JOOP!
I WENT BACK TO 7.6.3: 7.6.4 is unworkable. Is LibO no longer meant for Mac? I am a long time user, ever since OpenOffice, but I am beginning to give up: there have been all kind of strange errors on Mac like random re-zooming when hitting copy/paste, but this last problem is too much. Or is it because of my latest donation? Please do something. ;JOOP!
Created attachment 191423 [details] sample ODT with 13-pt Georgia sample text Thanks Camalaeón for the extra info. I still could not reproduce with the attachment; can you with the same file? Let' see if someone else can reproduce. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b2fd2c247f7f62f9ae6826c4f1b9065a50313217 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded @Sciuriware: please stay on topic here, the issue is font rendering on Linux. If you have other issues, and especially if they are macOS-specific, please search to see if they have been reported already; if so, subscribe to those; if not, it would be very much appreciated if you could open a new report. Thank you!
(In reply to Stéphane Guillou (stragu) from comment #11) > Created attachment 191423 [details] > sample ODT with 13-pt Georgia sample text > > Thanks Camalaeón for the extra info. > I still could not reproduce with the attachment; can you with the same file? > Let' see if someone else can reproduce. Yes, I can reproduce the issue with the provided file. See the new 2 added images: Image 5 from LO-DEV24 shows bad render. Image 6 from LO release shows good render. I will do more testings and checks on my side and add here any useful information I find.
Created attachment 191425 [details] IMAGE 5
Created attachment 191426 [details] IMAGE 6
I have the same problem in Xubuntu when upgrading from 23.04 to 23.10 It is not only happening in LibeOffice, but also in xfce's file manager Thunar and on the Desktop. I believe that this problem does only appear when anti-aliasing is set to off! This maybe the reason why Stephane could not reproduce it. Maybe there is a problem with hinting which is only present when anti-aliasing is off.
Created attachment 191528 [details] xfce settings to reproduce the problem problem seems to appear only with anti-aliasing set to off!
Created attachment 191529 [details] bad fonts in LibreOffice writer anti-aliasing off!
(In reply to Martin Dauskardt from comment #15) > I have the same problem in Xubuntu when upgrading from 23.04 to 23.10 > It is not only happening in LibeOffice, but also in xfce's file manager > Thunar and on the Desktop. > I believe that this problem does only appear when anti-aliasing is set to > off! This maybe the reason why Stephane could not reproduce it. > Maybe there is a problem with hinting which is only present when > anti-aliasing is off. If other apps are affected, this is likely "not our bug". But you might seeing something different to Camaleón. @Camaleón, are other apps affected? Does turning anti-aliasing on help? If you are able to, bibisecting the issue you see would help a lot: https://wiki.documentfoundation.org/QA/Bibisect
Well, the problem cannot be reproduced neither in LO release version nor XFCE itself (see attached image), so this is something introduced in LO latest devel version, which I tend to use precisely to watch this kind of things. My XFCE Appearance fonts settings are set as follow: Enable anti-aliasing [] Hinting: Full Sub-pixel order: None Of course, enabling anti-aliasing globally softens all texts and fonts borders but that's not the deal here.
Created attachment 191530 [details] XFCE text render is good
Your example in #20 does not show a good rendering! It shows clearly that the letters h, i, r and number 1 look bold.
(In reply to Martin Dauskardt from comment #21) > Your example in #20 does not show a good rendering! > It shows clearly that the letters h, i, r and number 1 look bold. Sure, that it is. The LO text looks/renders BAD (see image #20 left-side). The XFCE text sample looks/renders GOOD (see image #20 center-side). So the issue seems to stand on LO.
Camaleón: bibisecting as proposed by Stéphane in comment 18 is your best bet at the moment to investigate this. Please let us know, if you need help. Guidance can be provided.
(In reply to Buovjaga from comment #23) > Camaleón: bibisecting as proposed by Stéphane in comment 18 is your best bet > at the moment to investigate this. Please let us know, if you need help. > Guidance can be provided. I'll try the bibisecting path, time permitting. Will follow the provided instructions and send the findings as instructed. Given that the next stable release will be out soon (by the end of January?) and be based on current development version (24.x), I need this to be solved ASAP, otherwise stuck at 7.6.x (until it reaches EoL on June 2024).
bibisected c61a073e681ced79313f9bf70875c7899756d7aa is the first bad commit commit c61a073e681ced79313f9bf70875c7899756d7aa Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jan 17 17:28:49 2022 +0100 source bb495c6a2f00346698a041bce69a5a97effc79d7 source bb495c6a2f00346698a041bce69a5a97effc79d7 instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- instdir/share/registry/main.xcd | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
This is my first bibisection so maybe something can be wrong or missing... or both :-) Hope this helps to find the culprit here. I performed some tests using different git bibisected versions (24.2, 7.6, 7.5 and 7.4¹) and still keep all the files, so kindly ask should you need additional info or I run more/other testing. ¹https://wiki.documentfoundation.org/QA/Bibisect/Linux
(In reply to Camaleón from comment #25) > bibisected > c61a073e681ced79313f9bf70875c7899756d7aa is the first bad commit > commit c61a073e681ced79313f9bf70875c7899756d7aa > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Mon Jan 17 17:28:49 2022 +0100 > > source bb495c6a2f00346698a041bce69a5a97effc79d7 > > source bb495c6a2f00346698a041bce69a5a97effc79d7 > > instdir/program/setuprc | 2 +- > instdir/program/versionrc | 2 +- > instdir/share/registry/main.xcd | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) That seems plausible, commit subject is tdf#144862 set default render mode to LayoutAndMatchRender Let's ask Caolán what he thinks.
7.6.4 is reported as good, but 7.6.4 includes the commit in the apparent bisect: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-7-6-4&id=bb495c6a2f00346698a041bce69a5a97effc79d7 so if 7.6.4 is good and 24.2 is not, then it's not just the presence of that commit that matters. That said, document text in writer, calc, impress etc is not rendered with the exact same settings as text in widgets/menus etc. See the presentation at https://events.documentfoundation.org/libreoffice-conference-2022/talk/B87ZBP/ for the details there. But all of that is already in 7.6 IIRC. By guess is that our different settings for rendering document text triggers some bug in whatever is the combination of cairo+freetype+etc on that system. It should be the case that the gen backend menu/widget text is rendered with the same settings as the system suggests, unlike the document text which can differ a little, and the a in Table etc already looks a little rubbish (while the doc text looks very rubbish) so I feel its more than just the resolution independent stuff at play here. It might be that: export SAL_ALLOW_DEFAULT_HINTING=1 makes a difference (but I don't recommend that variable as it given known broken behavior)
Setting the environment variable «SAL_ALLOW_DEFAULT_HINTING=1» seems making no difference on my side when I run my usual LO 24.8.0.0.alpha0. The font hinting is still visually badly rendered. Maybe this is something related to this¹, but not sure how to get a «good» font rendering on my side (upwards 24.x LO releases) and this issue prevents me from upgrading. ¹How/where is font hinting performed in libreoffice? https://lists.freedesktop.org/archives/libreoffice/2023-November/091183.html
SAL_ALLOW_DEFAULT_HINTING not doing anything is sort of encouraging. That variable is the outcome of the linked thread FWIW. Can you report the version of cairo installed on your machine. And then I wonder if is possible to check the bibisect repo if things were better/worse before/after these commits: commit 5b52a7c3154f5263db82f19f7cc7d0e7b32da603 Author: Aron Budea <aron.budea@collabora.com> Date: Tue Sep 26 00:09:52 2023 +0200 tdf#152675 treat all cairo versions <= 1.17.8 the same (actually) commit 1dd357ccf7ca9edbe5f2ef60465c2559f678d306 Author: Caolán McNamara <caolan.mcnamara@collabora.com> Date: Sat Sep 23 07:16:06 2023 +0100 tdf#152675 treat all cairo versions <= 1.17.8 the same
Please keep in mind that the same font problem is also present in Xubuntu in some xfce tools, for example file manager thunar or in the xfce menu. It is not present in editor mousepad or wordpad (wine). Whatever it is, it can't be a library or setting which is exclusively used by Libreoffice. This Libreoffice version (snap package) has good font rendering: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: a9077e3fef0a06cb428c7a740a03f33bf70ac6ee CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: CL threaded while the version that comes with Xubuntu 23.10 has bad font rendering: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:7.6.4-0ubuntu0.23.10.1 Calc: threaded
could very well be related or affected by a specific version or config of a system lib. comparing versions of cairo is where I would start
1. As per the Cairo version installed on the system where I'm facing the issues with text hinting, it seems to be now at «1.18» on my current Debian testing: testing@netbook:~/linux-64-7.5$ dpkg -l | grep -i cairo ii gtk2-engines-murrine:amd64 0.98.2-3+b1 amd64 cairo-based gtk+-2.0 theme engine ii libcairo-gobject2:amd64 1.18.0-1+b1 amd64 Cairo 2D vector graphics library (GObject library) ii libcairo2:amd64 1.18.0-1+b1 amd64 Cairo 2D vector graphics library ii libcairomm-1.0-1v5:amd64 1.14.5-1 amd64 C++ wrappers for Cairo (shared libraries) ii libpangocairo-1.0-0:amd64 1.51.0+ds-4 amd64 Layout and rendering of internationalized text ii libpixman-1-0:amd64 0.42.2-1 amd64 pixel-manipulation library for X and cairo ii python3-cairo 1.25.1-2 amd64 Python3 bindings for the Cairo vector graphics library ii python3-gi-cairo 3.46.0-3 2. As per bibisecting, I already tried with these set of repositories and just 7.4 had a good version of the font: bibisect-linux-64-7.4 Xisco Fauli core commit 436f14c2 ← this worked bibisect-linux-64-7.5 Xisco Fauli core commit c94961c6 ← none worked bibisect-linux-64-7.6 Xisco Fauli core commit 1c629ca0 ← none worked bibisect-linux-64-24.2 Xisco Fauli core commit 6f227b0d ← none worked Should I try another one? If so, what would be the best to try? I'm not very fluent when it comes to Git terminology and usage. 3. On my current Debian testing, neither XFCE nor other programs experience issues with font rendering, just LibreOffice display bad strokes.
Just adding more information on this. To recap, after digging a bit more, the current situation is: - Computer 1. Debian testing / Cairo 1.18 / LibreOffice 24.2 (bad font render) / LibreOffice 7.6 (bad font render) - Computer 2. Debian stable / Cairo 1.16 / LibreOffice 24.2 (good font render) / LibreOffice 7.6 (good font render) So, IIRC, in Computer 1 _there was a time_ LO was rendering fonts fine, until I installed 24.2 (devel) where this issue with fonts hinting started. But in the meantime, Computer 1 it also upgraded the Cairo version (from 1.16 to 1.18) as logs shows: testing@netbook:~/Escritorio$ zgrep libcairo2 /var/log/dpkg.log.* | grep -i upgrade /var/log/dpkg.log.1:2024-01-13 09:19:31 upgrade libcairo2:amd64 1.18.0-1 1.18.0-1+b1 /var/log/dpkg.log.5.gz:2023-09-16 09:44:42 upgrade libcairo2:amd64 1.16.0-7 1.17.8-3 /var/log/dpkg.log.5.gz:2023-09-30 11:41:57 upgrade libcairo2:amd64 1.17.8-3 1.18.0-1 Et voilà, it was _not just LO_ what was updated but also Cairo library (I must sorry because I was not aware of this) which seems to trigger the LO font rendering problem when anti aliasing is disabled system wide. So the question is now: - What kind of change has been implemented in Cairo that makes LO render fonts so badly when anti-aliasing is turned off? And how can it be avoided and return LO its fine and crispy font strokes? - Why other programs (eg., XFCE itself, Firefox, Thunderbird...) seem unaffected to the Cairo change?
It seems to be reported in Cairo, I will keep an eye over it: Ugly Tahoma font rendering since version 1.17 https://gitlab.freedesktop.org/cairo/cairo/-/issues/809 So maybe Martin Dauskardt (comment #15) and Stéphane Guillou (stragu) (comment #18) were in the right path («not our bug!») :-)
I can confirm that with libcairo 1.16 the problem disappeared! My way with Xubuntu 23.10: sudo apt-get build-dep libcairo2 download https://gitlab.freedesktop.org/cairo/cairo/-/archive/1.16/cairo-1.16.zip cd cairo-1.16 ./autogen.sh ./configure --prefix=/usr/local sudo make install sudo ldconfig After a reboot the fonts are fine. I am missing some Debian-Patches but that doesn't seem to be a problem.
OK, let's close as "not our bug" then! Of course, if someone thinks something can be done on our end, please set back to "new". Thanks everyone.