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
Created attachment 191607 [details] bug demonstration
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.)
Created attachment 195731 [details] Example file at step 2
Bibisected with linux-64-6.0 to https://git.libreoffice.org/core/+log/51ee0c5ba6b0ffcd4b12e652de48e3f775cccc7d..d74b26b41bfea3ba7a1834953b2bfe9b7ff0d70f Range is a handful of RotateFlyFrame3 commits.
*** Bug 152907 has been marked as a duplicate of this bug. ***