Bug 158896 - EDITING: Baseline of text run persistently stuck on wrong position after cropping image anchored as character
Summary: EDITING: Baseline of text run persistently stuck on wrong position after crop...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Anchor-and-Text-Wrap Image-Crop
  Show dependency treegraph
 
Reported: 2023-12-28 00:21 UTC by demo4
Modified: 2024-01-11 16:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
bug demonstration (5.71 MB, video/mp4)
2023-12-28 00:22 UTC, demo4
Details

Note You need to log in before you can comment on or make changes to this bug.
Description demo4 2023-12-28 00:21:35 UTC
Description:
The pilcrow of an image (which is anchored as character) hangs, if the image is cropped in a specific way.

After an oversized image (higher than the page itself) has been cropped, the pilcrow is outside the page and is therefore not visible.

Steps to Reproduce:
1. Drop somewhere a random image (e.g. 10x10 cm) on the empty page
2. Change the anchoring to "character" (Context menu on the image >> Anchor >> As Character)
3. Toggle on the formatting marks. Note the pilcrow at the lower right corner of the image.
4. Toggle on the cropping mode (Context menu >> Crop)
5. Move the middle upper handle a bit down (eg. 2 cm). Note that there seems to be two pilcrows.
6. Move the middle lower handle a bit down or up.

Actual Results:
From now on, the pilcrow hangs at the same position relative to the upper edge of the image, even on resize. If now the anchoring is set to "to character" and then back to "as character", the pilcrow moves to the vertically center of the image, and even remains there, if the image is resized.

Expected Results:
The pilcrow should be placed on the lower corner of the image.


Reproducible: Always


User Profile Reset: No

Additional Info:
No other Information
Comment 1 demo4 2023-12-28 00:22:56 UTC
Created attachment 191607 [details]
bug demonstration
Comment 2 Stéphane Guillou (stragu) 2024-01-11 16:54:57 UTC
Thank you for the report.
There seems to be two separate issues:
A) the repaint issue at step 5 (two pilcrows visible, but any action should refresh the view and remove the ghost pilcrow). This can also be reproduced when resizing the image.
B) the persistent wrong line height, not matching the height of the image object, at step 6 (only happens when cropping). Unrelated to formatting marks. Any later action will not resolve the issue.

Let's focus on (B), which I think is more serious.

Reproduced in a recent trunk build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3cb1ed4339fc9aec414c0f112a69705a7a4d9cc6
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

And in 6.0.0.3

But I don't in 6.0.0.0.alpha1, so could be a regression in between.
(And this version confirms that the "ghost pilcrow" issue does predate the wrong line height issue.)