Bug 89818 - Long image inserted at the end of page goes beyond margin and over footer
Summary: Long image inserted at the end of page goes beyond margin and over footer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
Reported: 2015-03-04 15:47 UTC by rbruenner
Modified: 2022-09-27 13:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

odt and picture files describe the problem (773.29 KB, application/x-zip-compressed)
2015-03-04 15:47 UTC, rbruenner
Long image for reproducing (19.86 KB, image/png)
2015-03-15 17:54 UTC, Buovjaga
Here is the odt file (46.38 KB, application/zip)
2020-06-05 05:45 UTC, rbruenner
ODT file (47.96 KB, application/vnd.oasis.opendocument.text)
2020-06-05 06:53 UTC, Timur
ODT compared in MSO and LO (225.67 KB, image/webp)
2022-09-27 13:33 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description rbruenner 2015-03-04 15:47:35 UTC
Created attachment 113876 [details]
odt and picture files describe the problem

Page break does not work well with images.

In the attachment, you can find files to reproduce the issue.

Image 1 shows the situation after entering a high and narrow image at the bottom of the page. The image is already too high to fit on the page. However, the image and its accompanying paragraph does not get moved to the next page. The image is printed beyond the margins of the page. If there would be a footer, it would get overprinted.
Image 2: It gets even worse when there is text entered before. The image moves with the paragraph until the image touches the physical end of the page. It then stays there while the accompanying paragraph moves downward.
Image 3: More text - bigger problem!
Image 4: This is the maximum. The image is considerably moved relative to the text. I have orphan and widow control on and set to 2 lines. This is the worst that can happen. After entering more text, the paragraph would have to go to the next page.
Image 5: Yes, it does. And it takes its accompanying image with it. Now, the world is OK again. (Note: I also tried with orphan and widow control off. The same here. Wrapping to the new page only happens when the first line of the paragraph does not fit on the page.)

In step 1, it would already make sense to move the paragraph "Consetetur ..." to the next page and take the image with it, as can be seen in image 5. It is very bad that images do not obey page margins.
In step 2, the image looks as to be associated to a different paragraph. Additionally, causing one line to float around the image and the other one not, is not very pleasing.

It looks like the page break algorithm only takes the text into account. However, the image has to be considered as well.
Never should an image be moved beyond the page margin; this is non-printable area. If there is a footer, it will be partially obscured. Very bad.

When you have a document with many images and you are entering new text somewhere, you have to check all images beyond. This is frustrating. The only partial workaround is to use tables (sigh!). A one-line two-column table with the image and the text works. However, letting the text wrap AROUND the image is then no longer possible.

I have seen it very often in 4.1. In 4.3.6, the problem still persists.
Comment 1 Buovjaga 2015-03-15 17:52:59 UTC
Reproduced already in 3.3.0 with optimal page wrap.

Changed title as this is not about page breaks.

I wouldn't call this major severity, though, setting to normal: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Win 7 Pro 64-bit, LibO Version:
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 2 Buovjaga 2015-03-15 17:54:02 UTC
Created attachment 114113 [details]
Long image for reproducing
Comment 3 Stefan 2015-09-10 20:16:14 UTC
Reproduced with actual release.

Because of this bug declassifies LO absolut if you want to use (simple things like) images with text, priority is set to "high".

I'm writing a book. My document has 50 pages yet and 20 (small, embedded) images. So this is more then a letter, but, as you may think, no big thing for a powerful office tool like LO.

BUT: I have to deal with tons of bugs in LO (_some_ are reported here by me, have a look!). Imagehandling in LO is cruel, but this "normal" bug is a deathblow. How much images will "overlap" pagemargins in the descriped manner if i change something in my document, what do you think?

I'm a fan of OSS and a programmer of OSS-stuff too. But i can't recomment LO no more. Not at this state.
Comment 4 Buovjaga 2015-09-10 20:35:08 UTC
Stefan: our classification flowchart says:
"Does the bug prevent users from making professional quality work? Normal & medium"

If you are a programmer, I encourage you to look into fixing this bug. If you don't have time, you can hire a certified developer: https://www.documentfoundation.org/certification/developers/

As you are a fan of open source, surely you know that you can always recommend something when you get involved and thus are better able to improve lacking aspects.
Comment 5 Stefan 2015-09-10 21:16:58 UTC Comment hidden (obsolete)
Comment 6 Joel Madero 2015-09-11 00:07:14 UTC Comment hidden (obsolete)
Comment 7 Stefan 2015-09-11 09:48:16 UTC
@Joel: I'm really sorry about adding this bug at two lists :/

In which MAB this bug has to be posted (if this were important enough...)?

There is a image property "follow text flow" (set "off" by default), if set, the image will no more overlap, but will have a great distance to "its" paragraph sometimes.
Comment 8 Buovjaga 2015-09-11 10:19:12 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2016-09-20 10:32:38 UTC Comment hidden (obsolete)
Comment 10 rbruenner 2016-09-29 11:48:23 UTC
I have retried the issue with LO 5.1.2 on Mac OS X and with LO 5.1.5 on Windows 10.

The issue(s) basically remain the same.
There is one observation, though. When inserting the image (step 1) at various places in the document, a correct page wrap (i.e. to the following page) is achieved when the instert location is very low on the page.

All issues remain the same except for step 1 (inserting the high and narrow image on page 2):
a) inserting at the beginning of the first "Duis autem ..." paragraph shows margin overflow.
b) inserting the picture at the beginning of the "Ut wisi ..." paragraph inserts the picture so that it touches the physical end of the page (maximum page margin overflow) thus faking that it would belong to the paragraph before.
c) inserting at the beginning of the second "Duis autem ..." paragraph wraps the picture and the text to the following page.

I am not aware whether I have been testing the inserting step in such detail in the first place when reporting the issue, so it may have been there already.

To sum up, all the problems are still there: Big picture inserting does not reliably work, text inserting/deleting may move pictures on following pages beyond the page margins, and may cause pictures to look as if they are connected to the paragraph above when doing so.
Comment 11 QA Administrators 2018-05-15 02:31:06 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2020-05-15 03:46:10 UTC Comment hidden (obsolete)
Comment 13 Timur 2020-06-04 16:04:32 UTC Comment hidden (obsolete)
Comment 14 rbruenner 2020-06-05 05:45:01 UTC Comment hidden (obsolete)
Comment 15 Timur 2020-06-05 06:53:21 UTC
Created attachment 161634 [details]
ODT file

(In reply to rbruenner from comment #14)
> Created attachment 161630 [details]
> Here is the odt file
> Hello,
> Since I did no longer find the original file on my disk, I have created a
> new one in version which shows the problem.

OK, it's just single situation. It's not good practice to attach Zip, tester must unzip it and date changes, so I attach that ODT.

Bug is still here in 7.1+ with image anchored to paragraph or to character. Note another bug 132415 that hides text behind image with optimal page wrap. 
Behavior is different if anchor is "as character", image goes to the next page, as shown in attached ODT on 2nd page where image goes to 3rd page.
Comment 16 QA Administrators 2022-06-06 03:27:19 UTC Comment hidden (obsolete)
Comment 17 Timur 2022-09-27 13:33:37 UTC
Created attachment 182696 [details]
ODT compared in MSO and LO

Repro 7.5+. As seen in screenshot, MSO better handles image from the same ODT.