Bug Hunting Session
Bug 77468 - Lines at the bottom of some pages are missing
Summary: Lines at the bottom of some pages are missing
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
3.5.6.2 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-15 08:14 UTC by Star Man
Modified: 2015-03-06 05:45 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
This is the exported PDF. The final two lines are missing. (22.98 KB, image/png)
2014-04-15 08:14 UTC, Star Man
Details
This is the working document in Writer: it features the two missing lines from the exported PDF. (35.08 KB, image/png)
2014-04-15 08:15 UTC, Star Man
Details
Demo document (6.79 MB, application/zip)
2015-03-05 15:39 UTC, Adolfo Jayme
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Star Man 2014-04-15 08:14:10 UTC
Created attachment 97379 [details]
This is the exported PDF. The final two lines are missing.

When exporting to PDF, some pages have missing lines of text at the bottom. The exporter is unconsistent when exporting; some times they appear, but sometimes they do not appear.

Don't know what causes it, but is very unreliable for exporting long documents (we have to check page by page).
Comment 1 Star Man 2014-04-15 08:15:24 UTC
Created attachment 97380 [details]
This is the working document in Writer: it features the two missing lines from the exported PDF.
Comment 2 Star Man 2014-04-15 08:17:31 UTC
I've experienced the same issue with version 3.5.7 too.
Comment 3 Star Man 2014-04-16 16:37:06 UTC
The working document has more than 35 pages, makes extensive use of styles for paragraphs and pages; has embedded graphics produced with LO Draw and features lots of page-breaks (this is in case you have to test your own documents).
Comment 4 Adolfo Jayme 2014-08-04 04:22:32 UTC
Hi Star Man, thank you for your bug report.

We’ve just released LibreOffice 4.3, which features several improvements to the PDF import/export engine. Please retry with that version and tell us if you are still able to reproduce the problem.

Should you continue to experience the bug, it would be helpful if you could attach (or provide a link to) the affected document, only if it contains no private information.
Comment 5 Star Man 2014-08-15 00:06:48 UTC
I've seen this bug on LO 3.5.6, 4.1.x, 4.2.x and the current 4.3

Unfortunately the document I'm working on I cannot share because is private.

I'll try to reproduce this issue on a new document and send it to you. But if you can do this research too, the document should have lots of paragraph styles applied, many page styles also, many graphics produced on LO Draw mixing text and graphics, and more than 50 pages.
Comment 6 Star Man 2014-08-16 16:20:59 UTC
In the meantime I'm reproducing this document to submit for you, I'd like to point that, when attempting to export my 56-pages document to PDF, I first open the print-preview panel. Then, in the multiple pages preview I choose a grid of 8x7 pages.

At that oping, the 8x7 grid of pages is drawn page by page, from left to right. After it finishes drawing the grid, I notice the application re-scans the grid page by page again, the same order, and, in the case of my document, when arriving to the page no. 23, paragraphs reacommodate, and the same for the subsequent pages.

That means that the document I'm working on, and the document previewed on the print-preview panel are different (you saw the screenshot I took). Why is that happening that way?

So, in the end it makes document-editing somewhat unreliable, for sometimes the exported PDF will be missing lines ant the bottom of pages, wich are present in the original editing document.

I think this is an important bug to adress. I hope I can reproduce the document for you to analyze.
Comment 7 Star Man 2014-08-17 17:16:27 UTC
Finally!

I managed to scramble the document's text and replace its graphics, and still keep this bug showing up.

Notice that for this bug to show, the spanish dictionary found on http://extensions.libreoffice.org/extension-center/spanish-dictionaries (the generic one) should be activated. Otherwise it won't reproduce.

*This is because I'm a spanish speaker and I need my documents to be properly hyphenated. Using Ubuntu, I always need to install this extension right after the suite installation.

I have also embedded the document fonts so that it looks the same (because I don't know if they are part responsible for the bug.) They are open source fonts.

In the print-preview window, the rescanning of the document, mentioned before, makes changes to the positions of paragraphs from page 23 to page 36 (at least in my system), showing all the pages in a grid of 9x7

You can find this zipped document on the following link:

https://mega.co.nz/#!XQUCDBAS!EMud1QXV0arhJ4uP4lOFn8558XCAVGR4cm06-AeOxv8

Good luck!
Comment 8 Star Man 2014-08-19 23:36:07 UTC
I hope you had luck reviewing the document. The issues I'm about to cooment here I didn't tested with this document, but my original one.

Today I tested this issue on Mac OS X v10.6.8 using the same extensions. The bug appeared there also. There were missing lines at the end of the page 23 on my original document, exactly as the previous screenshots I posted here.

On Linux, today I also noticed another issue related to this bug. On the bottom end of page 46 on my original Writer document, the last paragraph ends about two lines above the page number. But, in the exported PDF, the same paragraph ends about just a single line above it. It's different, but it shouldn't be... It should export exactly as I'm editing in Writer.

I'm pretty sure this has to do with many Draw illustrations embedded into the document. When autoformatting, the engine does really strange things in combination with the hyphenation extension.
Comment 9 Buovjaga 2014-11-26 13:31:42 UTC
No need for NEEDINFO anymore.
Comment 10 raal 2015-03-05 15:00:09 UTC
(In reply to Star Man from comment #7)
> 
> You can find this zipped document on the following link:
> 
> https://mega.co.nz/#!XQUCDBAS!EMud1QXV0arhJ4uP4lOFn8558XCAVGR4cm06-AeOxv8
> 
Hello,
the file is not available.
Comment 11 Adolfo Jayme 2015-03-05 15:39:14 UTC
Created attachment 113917 [details]
Demo document

This is the document that was hosted at Mega.
Comment 12 Star Man 2015-03-05 15:55:20 UTC
I'm sorry. It was so many months ago that I erased it.
Could you please provide me with an email so I can send it zipped?
I'll recreate it using the current STABLE version in order to check if it was already solved. Thank you.
Comment 13 Joel Madero 2015-03-06 05:45:05 UTC
The sample document provided looks nothing like the png image so I'm not sure that it's useful at all. 

What I did:

1. Downloaded document from comment 11;
2. Observed page 27;
3. Exported PDF
4. Compared pdf page 27 to odt page 27

Both look identical to me.

I am closing this as WFM.

@Star - if you can still reproduce this issue we really need the documents to match. In other words, we need the damaged png's to represent the odt being shared - not that the png represents the original file and then the shared odt represents the stripped out odt - as these are impossible to compare.

Please test with the latest FRESH (not stable) - please note that FRESH is still stable - Fresh does not mean beta, alpha, or release candidate, it's still stable. If you can reproduce with Fresh - give us a clean zip that provides:

1. A document you're willing to share;
2. A pdf export;
3. A clear description of the difference.

After all of this you can set the bug back to UNCONFIRMED