Bug 163635 - Cursor completely misaligned while typing text in Impress 24.8
Summary: Cursor completely misaligned while typing text in Impress 24.8
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Impress-Bullet-Number
  Show dependency treegraph
 
Reported: 2024-10-26 12:57 UTC by Rafael Lima
Modified: 2025-01-11 15:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODP file (14.00 KB, application/vnd.oasis.opendocument.presentation)
2024-10-26 12:57 UTC, Rafael Lima
Details
Selection before 24.8 ODP vs. PPTX (63.05 KB, image/png)
2025-01-11 15:13 UTC, Aron Budea
Details
Selection in 25.8 ODP vs. PPTX (63.58 KB, image/png)
2025-01-11 15:13 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2024-10-26 12:57:44 UTC
Created attachment 197249 [details]
Test ODP file

While typing text in Impress 24.8 the cursor is vertically misaligned.

Steps to reproduce
1) Open attached test file in Impress 24.8
2) Click the last item in the list so that the cursor is blinking at the end of the text
3) Notice that the text cursor is vertically misaligned; it is being shown at a higher position than expected
4) Select some text and notice how the text boundaries and the cursor don't match

Expected results
In 24.2 the cursor is perfectly aligned; open the same file in 24.2 to see the desired results

System info

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
Comment 1 V Stuart Foote 2024-10-26 14:53:49 UTC
Cursor is sized as to the font metric of the bullet text spans. Highlight the text and you'll see the internal leading above and below.  Also, the bullet symbol is now taking its metrics from the font--still OpenSymbol, but it can be customized to any font any Unicode point, and the glyph used for bullet can be scaled. Template default is 45% 

When you match the font (bullet and text) they keep their alignment and the cursor matches the body height of the font.

IMHO => NAB and no regression.
Comment 2 Mihai Vasiliu 2024-10-26 15:39:03 UTC
Regardless of the scaling settings, this should not ever happen. Definitely a bug in my opinion. I encounter this issue quite often working with Impress.
Although this is only something visual, occuring only while editing, the related bullets allignment issue might fix this one as well, having most probably the same cause.

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
Comment 3 V Stuart Foote 2024-10-26 16:03:19 UTC
Select the text, or better change it to "Mhelp text" (to include cap M-h-p and a space glyph). Note the cursor will match height of the text run.  But it may remain off relative to the bullet since the bullet may not be the same font as the text.

Scaling/layout is done progressively as the text box is resized or as additional bullets are added. So fonts of both the bullets and the text runs are scaled proportionally. Not at full point (1/72") size increments, and certainly not in sync if different fonts.
Comment 4 Mihai Vasiliu 2024-12-12 21:40:49 UTC
Can reproduce in both

Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: ro-RO (ro_RO); UI: en-US
Calc: threaded

and 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
Comment 5 Aron Budea 2025-01-11 15:13:17 UTC
Created attachment 198490 [details]
Selection before 24.8 ODP vs. PPTX

Indeed, this started at the same commit as bug 163206 in 24.8:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=f61ea135430d7b4a1fac7de1e57a1314fbb1b49e
author		Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2024-03-28 12:30:34 +0900
committer	Tomaž Vajngerl <quikee@gmail.com>	2024-04-03 04:06:50 +0200

"editeng: use text scaling that better mimics MSO text scaling"

Attaching two screenshots for comparison, both showing similar ODP and PPTX side-by-side, one with the build before this commit from 24.8 bibisect build, and another with a recent 25.8 bibisect build. Note how the selection and layout is the same with PPTX, but very different with ODP (it could also be because the PPTX is less crammed), which seems expected from the commit, but indeed the bullets and the selection could be aligned better.
Comment 6 Aron Budea 2025-01-11 15:13:49 UTC
Created attachment 198491 [details]
Selection in 25.8 ODP vs. PPTX