Bug 107209 - Text layout error; text lines overlap randomly in long "complicated" documents
Summary: Text layout error; text lines overlap randomly in long "complicated" documents
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: Font-Rendering CJK-Japanese
  Show dependency treegraph
 
Reported: 2017-04-16 20:05 UTC by y3kcjd5
Modified: 2024-05-19 16:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document with broken text layout (5.70 MB, application/vnd.oasis.opendocument.text)
2017-04-16 20:06 UTC, y3kcjd5
Details
PDF of example document as rendered by version 5.3.2.2 (1.01 MB, application/pdf)
2017-04-16 20:07 UTC, y3kcjd5
Details
pdf version from LO 5.3.4.0.0+ (1.03 MB, application/pdf)
2017-04-19 17:56 UTC, Jean-Baptiste Faure
Details
Second example of broken document (211.68 KB, application/vnd.oasis.opendocument.text)
2017-04-19 18:54 UTC, y3kcjd5
Details
PDF of second example (1.17 MB, application/pdf)
2017-04-19 18:54 UTC, y3kcjd5
Details
pdf version of 2nd example from LO 5.3.4.0.0+ (1.16 MB, application/pdf)
2017-04-19 20:30 UTC, Jean-Baptiste Faure
Details
Font for first example document (4.35 MB, application/zip)
2017-04-22 23:41 UTC, y3kcjd5
Details

Note You need to log in before you can comment on or make changes to this bug.
Description y3kcjd5 2017-04-16 20:05:43 UTC
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
Comment 1 y3kcjd5 2017-04-16 20:06:35 UTC
Created attachment 132617 [details]
Example document with broken text layout
Comment 2 y3kcjd5 2017-04-16 20:07:32 UTC
Created attachment 132618 [details]
PDF of example document as rendered by version 5.3.2.2
Comment 3 Jean-Baptiste Faure 2017-04-19 17:56:39 UTC
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
Comment 4 y3kcjd5 2017-04-19 18:47:37 UTC
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).
Comment 5 y3kcjd5 2017-04-19 18:54:05 UTC
Created attachment 132695 [details]
Second example of broken document

Unfortunately the font was too big to embed this time
Comment 6 y3kcjd5 2017-04-19 18:54:36 UTC
Created attachment 132696 [details]
PDF of second example
Comment 7 Jean-Baptiste Faure 2017-04-19 20:30:20 UTC
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
Comment 8 y3kcjd5 2017-04-19 20:49:00 UTC
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
Comment 9 Jean-Baptiste Faure 2017-04-22 08:50:52 UTC
(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
Comment 10 y3kcjd5 2017-04-22 23:41:36 UTC
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.
Comment 11 Buovjaga 2017-04-28 16:25:50 UTC
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)
Comment 12 QA Administrators 2018-04-29 02:30:37 UTC Comment hidden (obsolete)
Comment 13 y3kcjd5 2018-05-20 04:48:40 UTC
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).
Comment 14 Xisco Faulí 2019-05-15 10:13:47 UTC
it can't be a regression if it's inherit from OOo
Comment 15 QA Administrators 2021-05-15 04:17:31 UTC Comment hidden (obsolete)
Comment 16 y3kcjd5 2022-03-01 21:04:45 UTC
Persistent as of version 7.3.0.3. The "wrinkles" were found in the first example document on page 1 this time.
Comment 17 QA Administrators 2024-03-01 03:16:51 UTC Comment hidden (obsolete)
Comment 18 y3kcjd5 2024-05-19 13:27:49 UTC
Persistent as of version 24.2.3.2, with displacement in the example document on pages 1, 2, 22, and 28
Comment 19 Buovjaga 2024-05-19 16:13:18 UTC
(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