Bug 131302 - Hidden hard linebreak character inserted between image and its caption
Summary: Hidden hard linebreak character inserted between image and its caption
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://ask.libreoffice.org/en/questi...
Keywords: bibisected, bisected, regression
: 131303 (view as bug list)
Depends on:
Blocks: Caption
  Show dependency treegraph
Reported: 2020-03-12 07:30 UTC by Mike Kaganski
Modified: 2024-04-28 03:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-03-12 07:30:26 UTC
When a caption is added to an image, there's a hidden linebreak character between the image and the inserted caption.

1. Insert an image
2. Right-click it and add caption with some text
=> this creates a frame holding the original image (now having "As Character" anchoring) plus inserted caption, both in the same paragraph
3. Select the image (not the frame!) and drag its lower right handle to shrink it to allow the image and its caption to be on the same line
4. Put cursor in the caption, and use left arrow key to step through characters up to the image

There's a step when the cursor gets to the left of the first character of the caption, staying between the caption and the image, when the next press of left arrow does not move it, but only changes its size. The next press after that finally moves it to the left of the image.

The hidden character may be selected, and its direct formatting be cleared to make it not hidden.

The user-visible problem with the character is that it's shown as leading space in figure index (see https://ask.libreoffice.org/en/question/233189/).

In versions 5.0 and earlier, the image was anchored "to paragraph", and there was no characters before first character of caption in the caption's paragraph.

The hard break was introduced for v.5.1 in https://gerrit.libreoffice.org/plugins/gitiles/core/+/93ab0ff24cb71c36c9e7958046e96d7472b5af90 (related to tdf#93676).

The hidden attribute was introduced for v.5.3 in https://gerrit.libreoffice.org/plugins/gitiles/core/+/feedd45ba2dd308af2d3a1b2f64681b9467535b6 (which BTW broke the idea that hard break should keep the graphic separated from the caption text if the outer frame is resized).

Removing the character doesn't bring immediately observable problems (it works as with it, because hidden hard break does effectively nothing for text flow). However, simply removing it looks incorrect if potential fix for tdf#65323 is taken into account (which would make an as-char image to behave as printed "alphabetic-like" character, which could disallow automatic line break between the image and the immediately following alphabetic character). IMO, a better fix would be to keep image anchored as character (as it is now), but make a separate paragraph for it (using the same Figure paragraph style; separate dedicated style seems to not be required, since figure index does not list paragraphs without number range field), and put the caption on the next paragraph.
Comment 1 Mike Kaganski 2020-03-12 08:42:14 UTC
*** Bug 131303 has been marked as a duplicate of this bug. ***
Comment 2 Dieter 2020-03-18 12:37:16 UTC
I confirm it with

Version: (x64)
Build ID: 5dcbd1bb557450a2d658a710c163b310c0cee157
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: CL

But I can't say what would be an appropriate solution.
Comment 3 Gabor Kelemen (allotropia) 2022-04-28 11:33:21 UTC
For the record: the problematic changes were reverted in bug 123801
Now the pre-5.0 state is restored.

There is also a bit of discussion about how to do this better in bug 121378.
Comment 4 QA Administrators 2024-04-28 03:16:17 UTC
Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team