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
See pdf (page 22, center division, left-ish side).
Text should align nicely.
User Profile Reset: No
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 184.108.40.206
Created attachment 132691 [details]
pdf version from LO 220.127.116.11.0+
Seems to not be reproducible for me with LO 18.104.22.168.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 22.214.171.124.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
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 126.96.36.199 (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!
Confirmed persistent on version 188.8.131.52 (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