Created attachment 178921 [details] Video showing the problem Occasionally clicking on a slide text will make the spacing between lines change for no apparent reason, which makes it very difficult to prepare a slide that will look "stable". See the attached video. When I open the file, there's very few spacing between lines. Then when I click another text box, the line spacing increases. Clicking back in the slide text will make line spacing reduce again. Repeating this cycle for some time will make the problem eventually stop, but then all of a sudden it starts happening again. To reproduce this bug: 1) Make sure you have the correct fonts installed (Lato and Bitter from Google fonts) 2) Open the sample ODP file, which is the one I used in the video 3) Click anywhere in the slide text 4) Now click the text box in the middle of the slide 5) Notice the line spacing changing 6) Keep clicking in and out of the slide text and at some point the problem will stop This problem does not happen all the time, but it happens very often with me. Maybe it has to do with font height calculations, but this is just a guess. The video was make using LO 7.3.1 but this issue has happened since at least 7.1. System info: Version: 7.3.1.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 12; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.1~rc3-0ubuntu0.21.10.1~lo2 Calc: threaded
Created attachment 178922 [details] Sample ODP file This is the ODP file I used in the video.
I am using the font Lato by Google and it is the only font I've tried where this bug happens. This leads me to believe this bug has something to do with how LO deals with this font (and possibly other similar fonts).
I repro with 7.4 and master even without Lato or Bitter installed, but in my Fedora container I don't see the issue with the words per line changing (there is some change that could be about line height or font scale somehow). I can't repro the words per line change on Windows either. Rafael: do you think the bad target here is the height/scale change specifically and not the words per line change? Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0160109aae49189f5cc9bed60db3c7084003e471 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 16 January 2023 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 37e3455a13ab5741104bf41d05a80e60a4612682 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #3) > Rafael: do you think the bad target here is the height/scale change > specifically and not the words per line change? I think the problem has to do with how the line height is calculated. The "words per line" problem is a consequence, because when the line height changes, LO reduces the font size so the text can fit in the text box. It problem has to do with the calculations done when Autofit Text is enabled. When I disable it, then the problem disappears (but also the text no longer automatically fits inside the text box)
In the comment above there's a typo. I meant: It seems the problem has to do with the calculations done when Autofit Text is enabled.
First line height change (only "O que são heurísticas?") happened in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a1ac2538e9b287444500618ab4d2f0f06c25cf34..19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 where the likely culprit is https://git.libreoffice.org/core/commit/6fbba11da54b52554941f00b07e42cc5d7a1643c fdo#55430 click object in front of current after editing text The next change was such that "O que são heurísticas?" didn't jump anymore, but the last line of the next paragraph did. I bisected it with Linux 42max to commit a071978f128cbbd6f08c10626225c923cf23b8b9 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 21:17:48 2015 +0800 source-hash-d45ba6bb93a5325341cef6b9f25282537265de5d Bibisect: This commit covers the following source commit(s) which failed to build d023339c2f85555212bdb9804854dcc2c403b50e 50cbbc7f3afdd077e98f416f97390fe93428e8cf 6936fa4a100576c56fddb68d3879df2693c52bda b1314f22eb8de4359b5360194c04996351e9a6c2 3f0e95cdc5fac1658ac25b97e0d9532ed76a009c where the relevant seems to be https://git.libreoffice.org/core/commit/d45ba6bb93a5325341cef6b9f25282537265de5d missing file which added sd/source/ui/sidebar/MasterPageObserver.cxx Although the others deal with Impress as well (Sidebar). The next bigger change is in 5.4. There the steps are a bit more precise. Focus into text input in both the yellow box and the bigger box and then select the yellow box. All lines in the bigger box get their height changed. This happens after https://git.libreoffice.org/core/commit/451fcee7f7c2bdc5a9241662c412027672df3a1c tdf#97630 xmloff: ODF extended draw:fit-to-size mess The final change seems to be in 7.5, with the effect seen with line wrapping: https://git.libreoffice.org/core/commit/7f73a779e33dd91fad0111629c6b3420c2c9aea0 optimize text fitting algorithm to correctly calculate the fit
No problem in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a34dcd03254480927c403d904c0e754802d97b90 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Could you retest it, to be sure it is solved?
(In reply to BogdanB from comment #7) > Could you retest it, to be sure it is solved? I can still reproduce the original problem in: Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: 60(Build:2) CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:7.6.1~rc2-0ubuntu0.23.04.1~lo1 Calc: threaded I feel this might be related by how Impress calculate the height of a line of text. Disabling "Autofit Text" makes the problem go away (although the text no longer autofits inside the text box)
Hi Mike, I noticed you've been working on some text rendering bugs. Do you have any idea what might be happening here? This bug is still happening for me... it seems like a miscalculation of the text size.