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.
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
Created attachment 114113 [details] Long image for reproducing
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.
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.
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)
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.
@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.
(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.
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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.
** 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
Dear rbruenner, 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://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
Please attach ODT, it's not in ZIP. Please test with different image anchors.
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 6.1.6.3 which shows the problem.
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 6.1.6.3 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.
Dear rbruenner, 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
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.