Description: When changing a bulleted list on a slide, the bullets position is changing randomly (drifting) relative to the center of the line. Steps to Reproduce: 1. Open or create a new Impress presentation 2. Add a new Title,Content slide 3. Change the bullet type to any arrow type (to make the issue more obvious to see) 4. Add elements to the bulleted list (at least 8-9 elements) 5. Observe the bullet positions 6. Remove half of the list elements 7. Observe the bullet positions again. 8. Click outside of the text area 9. Bullet positions are changing again. Actual Results: In steps 5, 7, 9 the bullets are drifting randomly relative to the center of the line. Expected Results: The bullets should never change position relative to the center of the line. Reproducible: Always User Profile Reset: No Additional Info: I think this is a side effect of the text font size auto-scaling in the text box that needs to be addressed. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded
Created attachment 196785 [details] Screenshot of the bullets after drifting
See the effect. If I simply remove the Paragraph style spacing 'Above paragraph' (set to 0.20" by default) the bullet markers (which are also scaled at 45% but can be set unscaled) will align with the bullets, no shift. Also, can change the font of the Paragraph to match that of the bullet marker, so to OpenSymbol to follow default markers. Adjusting default spacing, scaling and font brings the bullet markers in line with the text. Meaning they get handled correctly in VCL layout. And that matches behavior of bullets in Writer. Any movement is simply a styling effect--the bullets position in response to spacing and scaling when the content paragraphs have cursor focus rather than the text box frame. => NAB Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
If it's not a bug, why does this drift happen by default? I didn't change any default settings and this still happens. I tried setting the Above paragraph setting to 0 or any value, but the bullets still are misplaced for me. It is not easy or obvious how to make them properly aligned. I messed with the settings and still cannot make them alligned. In my opinion this behaviour should not happen by default as it is a bad user experience. The bullets should always be centered on the line.
Not a bug because the bullets are doing exactly what we tell them to do. A bullet glyph in OpenSymbol font scaled 45%, placed on a paragraph line (in a different font--Liberation Sans) that has a 0.02" spacing above it. If you set same font, scale bullet to same size, with the paragraph line spacing to match--they are exactly centered. The "drifting" has always been this way (apparent movement between when selected for edit vs. as viewed or presented).
Created attachment 197247 [details] Explanation of the issue I've been noticing this issue too... and it's very annoying when preparing my lectures (I was about to report the same thing as well). If this is NAB, then this is an awful default to have. Try this (which is my main issue): 1) Create a blank Impress document 2) Change the slide layout to "Title, content" 3) In the "content" area there's a bullet 4) Type "Text". The bullet will be vertically centered (OK) 5) Press Enter (here's another new bug; the bullet won't use the "Above paragraph" spacing; will report in a separate ticket) 6) Now type "Text" again; the bullet will fix itself and be centered 7) Now type "Text" and ENTER 3 more times (5 in total; don't press Enter on the 5th time); the bullets will remain vertically centered as expected (OK) 8) Now press Enter and type the 6th "Text" 9) Notice the bullets now start drifting upwards 10) Keep adding more lines to see how bad it can get In steps 8-10 clicking inside to edit the shape and then outside to deselect the shape will cause the bullets to move up and down This feels too buggy to me. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 480(Build:1) CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:24.8.2-0ubuntu1 Calc: threaded
Created attachment 197248 [details] Test ODP file I would say that this is a regression, because in 24.2 we get a different (and more desirable) result. And in 24.8 this changed and now all my bullets are misaligned in my lectures. Open this test OPD file both in 24.2 and 24.8 to see the difference in rendering (this file shows the result of steps 1-8 from comment 5). In 24.2 the bullets are better aligned. In 24.8 the bullets are very misaligned. Also, the other bug from Step 5 does not happen in 24.2. Moreover, I notice that the cursor is also misaligned when typing.
I belive this may be a dupe of my bug 163493. I noticed this too when I was working on the presentation for this year's LibOCon.
(In reply to Eyal Rozenberg from comment #7) > I belive this may be a dupe of my bug 163493. I suggest to make your ticket a duplicate of this because of the more elaborated STR.
*** Bug 163493 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #2) > > => NAB Oh, it's a bug alright. A bullet must be properly aligned with the bulleted to text - even if the bullet is of a different font. This what users expect, and this is what presentation viewers expect. The breaking of this alignment is the atypical behavior which may require some careful manipulation/settings; but doing nothing, there must be alignment. Now, the question what exactly this alignment constitutes is a little more tricky, since fonts have many metrics. But whatever the rule chosen, it must agree with the exepctation in the most common of cases. So, the v-center of the bullet glyph of OpenSymbol needs to align with the v-center - however we define that - of the bulleted paragraph's first line. In the specific case of attachment 197248 [details], the bullet's v-center should align with the v-center of the "x" in "Text", more or less. > Any movement is simply a styling effect --the bullets position in response to > spacing and scaling when the content paragraphs have cursor focus rather > than the text box frame. It is legitimate for intentional styling to get the bullet v-shifted relative to the v-center of the bulleted line; but - not the default styling, and not the merge changing of bullet typeface or font size.
(In reply to V Stuart Foote from comment #4) > Not a bug because the bullets are doing exactly what we tell them to do. Well, the user did not tell them to dis-align from the text. Indeed, we "tell" them to - and that's the bug. We should tell them something else.
Created attachment 197324 [details] Screenshot of the issue Here's a presentation I'm preparing right now. The situation with the bullets is terrible in 24.8. In 24.2 it was ok.
(In reply to Rafael Lima from comment #12) > Here's a presentation I'm preparing right now. The situation with the > bullets is terrible in 24.8. In 24.2 it was ok. I also remember this behavior started relatively recently. I'll also say that the fact that we released with a bug that's this prevalent makes me wonder if our procedures for testing, prior to releases, should not have caught this somehow.
I was able to reproduce the bug and bibisected mac64-24.8 1b1ae22430deb6c50d058b6233d3fa828ac5c80c is the first bad commit commit 1b1ae22430deb6c50d058b6233d3fa828ac5c80c Author: libreoffice <libreoffice@libreoffices-MacBook-Air.local> Date: Thu Jun 13 23:54:05 2024 +0200 source f61ea135430d7b4a1fac7de1e57a1314fbb1b49e source f61ea135430d7b4a1fac7de1e57a1314fbb1b49e .../Contents/Frameworks/libeditenglo.dylib | Bin 2749112 -> 2749504 bytes .../Contents/Frameworks/libsvxcorelo.dylib | Bin 10441864 -> 10441712 bytes .../Contents/Resources/gallery/sounds.sdg | Bin 18048 -> 18045 bytes .../Contents/Resources/gallery/sounds.thm | Bin 1457 -> 1457 bytes LibreOffice.app/Contents/Resources/setuprc | 2 +- LibreOffice.app/Contents/Resources/versionrc | 2 +- 6 files changed, 2 insertions(+), 2 deletions(-) Version: LibreOfficeDev 24.8.0.0.alpha0 f61ea135430d7b4a1fac7de1e57a1314fbb1b49e Found Author and commit using source sha: https://git.libreoffice.org/core/+/f61ea135430d7b4a1fac7de1e57a1314fbb1b49e%5E%21 Note: I also tested the previous commit to the bad commit and it does not have the bug. The previous commit of the bad commit (does not have bug): e9927a82543168442901c89f29a23941e7af2f8d When testing the bad commit and the previous commit, try with at least 9 bullet points with the word "Text" next to each one (as per the reporters instructions).
*** This bug has been marked as a duplicate of bug 163634 ***
Although this is related to Bug 163634, this one is not the same behaviour and it is not a duplicate of it. Verified this one is NOT fixed in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a5149eadb23825a9fb5beeda81836ad7940c3083 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: CL threaded