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)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2015-03-04 15:47 UTC by rbruenner
Modified: 2018-05-15 02:31 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
odt and picture files describe the problem (773.29 KB, application/x-zip-compressed)
2015-03-04 15:47 UTC, rbruenner
Details
Long image for reproducing (19.86 KB, image/png)
2015-03-15 17:54 UTC, Buovjaga
Details

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: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
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 4.4.5.2 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
This old bug makes LO useless if you will work with more then 3 paragraph-embedded images.
But, as you say, maybe it's "normal" and "medium".

I'm a programmer, but i'm here because of i try to write a small book with LO (as i wrote). I spend _many_ hours in handling "my bugs" at "writing-time" and some hours to report them here:
https://bugs.documentfoundation.org/buglist.cgi?email1=slub%40gmx.de&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&list_id=557467&resolution=---

I can´t do no more at this time. (And i think 99.999% of frustrated users don't give a fuck to report tens of little nagging bugs, so this is much)
Comment 6 Joel Madero 2015-09-11 00:07:14 UTC
please don't add things to the MAB tracker without knowing procedures, additionally, MAB is pretty much retired at this point. We use priority/severity field (objectively) instead.

In this particular case the bug was added to two MAB trackers which is incorrect. But removing from both since again, the tracker is basically retired at this point.

Please don't mess with those settings on top again - it was already prioritized correctly by QA.
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...)?
https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs

BTW:
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
(In reply to Stefan from comment #7)
> @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...)?
> https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs

MABs are retired in favor of priority: highest. Soon the priority field will be locked from editing by default and access will have to be requested from the QA team.
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
** Please read this message in its entirety before responding **

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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug