Description: I'm not sure what the exact conditions for this are, but some combination of resized images, vertical text, page dividers, and possibly furigana (i.e. stuff which requires lots of precise width tracking) results in some lines of text being displayed in incorrect locations (see attachment documents). It's possible to poke at the problem areas by editing in the vicinity (e.g. deleting and re-entering paragraph breaks) but it's like trying to smooth out bedsheets; straighten out wrinkles in one spot and they probably pop up elsewhere nearby. Also, even if you manage to get rid of the display error, if you haven't actually changed the text contents (e.g. re-entering paragraph breaks), the problem will return on a save/reload. The attachment's I'm adding now are accurate for version 5.3.2, but I saw the location of the 'wrinkles' change in updating from 5.1.2 so if your view of the .odt doesn't match the .pdf, just scan through the whole document; they're probably in there somewhere. Steps to Reproduce: 1. Enter lots of different content with weird zoom values or widths 2. Add lots of text 3. Scan through the document Actual Results: See pdf (page 22, center division, left-ish side). Expected Results: Text should align nicely. Reproducible: Sometimes User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Created attachment 132617 [details] Example document with broken text layout
Created attachment 132618 [details] PDF of example document as rendered by version 5.3.2.2
Created attachment 132691 [details] pdf version from LO 5.3.4.0.0+ Seems to not be reproducible for me with LO 5.3.4.0.0+ built at home under Ubuntu 16.04 x86-64. I do not have the correct font, seems to be substituted by Noto font. Please could you check if my pdf is better than yours? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested information is provided. Best regards. JBF
Your pdf indeed looks better than mine; I didn't see any of the overlaps in your version. I find it a bit strange that the font didn't show up, since I told the file to embed fonts (File→Properties) I tried a couple other fonts on my system and that particular example didn't show the issue anymore with those fonts, so I suspect that to be an issue. As such, I'm uploading a slightly modified version with a more common font (Meiryo).
Created attachment 132695 [details] Second example of broken document Unfortunately the font was too big to embed this time
Created attachment 132696 [details] PDF of second example
Created attachment 132699 [details] pdf version of 2nd example from LO 5.3.4.0.0+ Here is my pdf export of your second example. I do not see any overlapping. Best regards. JBF
This is rather strange, did the second example show up as using Meiryo as its font or did your system make a substitution again? Comparing the 4 pdfs we've produced, they all look quite different from each other. I'm using Windows 7 64bit
(In reply to y3kcjd5 from comment #8) > This is rather strange, did the second example show up as using Meiryo as > its font or did your system make a substitution again? The name of the font is メイリオ; the font is not installed and is substituted. Best regards. JBF
Created attachment 132758 [details] Font for first example document In that case I'm uploading the font for the first example document; hopefully if it's installed directly it won't make a substitution; the fact that the embedded version didn't work suggests that something's broken there too, though.
Installed font and confirm the overlap. In 3.6 there is not overlap. I guess this is because of the new layout engine and thus does not need to be bibisected.. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 9348b322a5c230dfcc2231661b73e480b130fcd9 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 28th 2016 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
** 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
Confirmed persistent on version 6.0.4.2 (using first example document and its font). Tested on version 3.3.0 and the 'wrinkles' were in a different place but still present (page 23 instead of 22).
it can't be a regression if it's inherit from OOo
Dear y3kcjd5, 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
Persistent as of version 7.3.0.3. The "wrinkles" were found in the first example document on page 1 this time.
Dear y3kcjd5, 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
Persistent as of version 24.2.3.2, with displacement in the example document on pages 1, 2, 22, and 28
(In reply to y3kcjd5 from comment #18) > Persistent as of version 24.2.3.2, with displacement in the example document > on pages 1, 2, 22, and 28 Also in a fresh master build. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 7e36bbd142ea80969c15f384759102d8175dedc3 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
I've been investigating this issue, specifically focusing on the first instance of overlapping text that is present on page 1 in the current master branch. This issue happens when laying out a paragraph of vertical right-to-left text which overflows the current page/column and is to the left of a fly portion. Based on this observation, I was able to create a much simpler reproducer for this issue, which I will attach in a following comment. The root cause for this issue is Writer failing to restore some global state during recursion.
Created attachment 194788 [details] Simple reproducer Simple reproducer showing the incorrect placement. Note that this document is vertical right-to-left. The paragraph with the 'A's comes before the paragraph with the 'B's (i.e. all 'B's should be to the left of all 'A's). Unfortunately, due to the nature of this type of bug, the behavior of this document may change unpredictably between versions. At time of writing, the 'B' lines are incorrectly positioned somewhere between the 'A' line and the image.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c7f1e41ca672f6bb1055b92012fff0d92a5ff805 tdf#107209 Writer correct vertical text break after fly portions It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The recursion issue I mentioned previously turned out to be a red herring. The root cause was a simple implementation bug, dating back to the original vertical formatting commit (~2001). With this code change, the document in https://bugs.documentfoundation.org/attachment.cgi?id=132617 now displays correctly for me. I am therefore marking this bug fixed.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/00d6f1f64a6eb93b7a5544fb612118c9ccf1cf50 tdf#107209 Writer correct vertical text break after fly portions It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.