Bug 71463 - UI: Frame with nowrap and follow text misbehave when moved to the next page
Summary: UI: Frame with nowrap and follow text misbehave when moved to the next page
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Writer-Styles-Frame
  Show dependency tree / graph
 
Reported: 2013-11-11 07:18 UTC by Luiz Angelo Daros de Luca
Modified: 2024-06-23 03:16 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
example doc (37.22 KB, application/vnd.oasis.opendocument.text)
2013-11-11 07:18 UTC, Luiz Angelo Daros de Luca 		Details
Better example of the problem (56.73 KB, application/vnd.oasis.opendocument.text)
2014-01-09 14:27 UTC, Luiz Angelo Daros de Luca 		Details
image overlap the second one (56.26 KB, image/png)
2014-01-09 14:40 UTC, sophie 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Luiz Angelo Daros de Luca 2013-11-11 07:18:46 UTC 
Created attachment 88993 [details]
example doc

I have been experiencing this bug since a long time ago in Open/Libreoffice, even in earlier times.
However, now I might have isolated a testcase.

I always uses the LO caption function for figures. It creates a frame over it and add a line with a description (and a incremental number). I also always setup this frames to be:

Anchor: paragraph
Width: 100%, relative
Height: I do not change the default value, but I make sure to set "autosize"

Position:
hoz: center to Paragraph area
vert: top to Paragraph text
"Follow text flow"

And for wrap, none.

I keep a dedicated paragraph for each frame. I hope that these settings would prevent me to have frames overlapping other frames (because of wrap none). Also, they will keep in order with paragraph position, even if it needs to leave a significant white space in the previous page.

However, frames always dare me!

I know that I could simulate the behavior I need using frames as characters. However, I loose some controls that I wanted as alignment to paragraph (I would need to use special spacing setting to put it in the middle of a page). Also, "anchor to paragraph" seems to be the recommended usage of pictures, as it is the default one.

In the attached doc, I put two simple frames (blue and red) with the confs I wrote before. The first (blue frame) is anchored to the first page. The second one (red) just follows it, anchored to a following paragraph. When I put enough white lines in the first page in order to have no space for blue, it is moved to the second page. This is ok. However, for some reason, sometimes, it is over red frame. LO plays tricks on me. Sometimes it:

1) keeps the wrong position (overlapping)
2) fixes it a second after I look at it (seems to be an after draw check wrote as a workaround)
3) fixes only after I click on the frame
4) just works.
5) places blue on the top of a third page, even with plenty place to put both images on page two.

The worst of all these is that doing reversal operations, like adding a line and removing it, can trigger the problem. Sometimes, even undo cannot recover it, sometimes it does.

This is a nightmare for large docs. I lost some hours reviewing PDF files, picture by picture, every time I need to generate a new version.

It seems to be more common when I use "autosize" with minimum size smaller than the needed one. Also, it is harder to reproduce the overlapping bug without pictures inside the frame (but I can reproduce the "blue on the third page")

Just play adding/removing lines in the attached doc that you'll see a bunch of strange behaviors.

PS: the "wrap none" behavior, besides this random state bug, does not make sense to me. It only applies to text and not to floating objects, even if they are also configured as "wrap none". This is a area that even experienced users have problem to deal with. For newbies, this is hell. I already helped a bunch of them with no great terminal solution. Why not treat them like a table? 
Operating System: Ubuntu
Version: 4.1.2.3 release
Comment 1 sophie 2014-01-08 15:11:07 UTC 
I've tried to reproduce the behavior you mentioned with no success, the frame always jump at the right place. Could you give us a document where it overlaps or jump at the wrong place? Sophie
Comment 2 Luiz Angelo Daros de Luca 2014-01-09 14:26:16 UTC 
Thanks Sophie,

It seems that the random behavior is less present because of some change between 4.1.2.3 and 4.1.3.2. I'll attach a second doc that is better to reproduce problems.

For the first test, in the second doc, just keep adding paragraph after the mark (close to the top of the first page). Eventually, the red frame goes to the second page (no problem). If you add more, "Anchors red frame" goes to the next page (no problem). If you add even more in order to blue frame not fitting on the first page, it goes to the next page. Here comes the problems. Blue frame is over some paragraphs, including the "Anchors red frame". If you play with mouse selection/scrolling the hidden text (and not changing a single bit of the doc), the frames eventually get separated (which is the expected final result). As selecting text is not an "editing operation", this is a bug. The correct final result can also be obtained if you add enough paragraph in order to have no space in page 1 and undoing it with ctrl+z.

Another problem is even worse. Reload the second doc in order to undo changes. In this second test, I marked a line to be removed between the blue and the red frame. Keep just the "Anchors red frame" line. If I add again lines before the "Anchors blue frame", like in the first test, when there is no more space for red frame, the figure inside the frame is just removed! I can undo and it does 
not come back. No resize makes it back, only reloading the doc (and discarding changes).

If you are working for hours, image the user react. If the user is not saving the doc (but using autosave for security), he/she have the only option to readd the figure or to discard all his work. The severity is very high here.
Comment 3 Luiz Angelo Daros de Luca 2014-01-09 14:27:16 UTC 
Created attachment 91752 [details]
Better example of the problem
Comment 4 sophie 2014-01-09 14:39:42 UTC 
ok, this time I reproduced with your second test, thanks for the new attachment. I'll add a screenshot of the overlap. Set to new - Sophie
Comment 5 sophie 2014-01-09 14:40:46 UTC 
Created attachment 91758 [details]
image overlap the second one
Comment 6 Joel Madero 2015-05-02 15:42:45 UTC Comment hidden (obsolete)
Comment 7 Gordo 2015-06-20 16:02:42 UTC 
Still reproducible.

The frames are anchored to paragraphs and when there is not enough room on the page for the frames then the those paragraphs are next to each other and the frames overlap.  The images are anchored to paragraphs in the frames and because the frames overlap then those paragraphs are close together and the images overlap.

I turned off follow text flow on both frames and could not reproduce this bug.

Also, when a caption is created, the image is anchored to paragraph and that paragraph is the caption.  I anchored the image to the frame and was not able to reproduce this bug.

Windows Vista 64
Version: 4.4.4.2
Build ID: f784c932ccfd756d01b70b6bb5e09ff62e1b3285

Version: 5.1.0.0.alpha1+
Build ID: 46564fd97308ce070248482ad65a311a329a2b76
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-15_00:08:53
Comment 8 QA Administrators 2016-09-20 10:09:43 UTC Comment hidden (obsolete)
Comment 9 Luiz Angelo Daros de Luca 2016-12-12 18:53:29 UTC 
Still on 5.2.3.3
Comment 10 QA Administrators 2018-06-22 02:49:12 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2020-06-22 03:38:50 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2022-06-23 03:47:44 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2024-06-23 03:16:38 UTC 
Dear Luiz Angelo Daros de Luca,

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

MassPing-UntouchedBug