Bug Hunting Session
Bug 72919 - Other: UNO-API PDF Mass Export breaks layout
Summary: Other: UNO-API PDF Mass Export breaks layout
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA needsWindows
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2013-12-20 15:37 UTC by Wahrendorff
Modified: 2018-11-13 16:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Eclipse project reproducing the error under windows (2.19 MB, application/zip)
2013-12-20 15:37 UTC, Wahrendorff
Details
Tests the "virtual printing" (2.19 MB, application/zip)
2014-02-03 08:57 UTC, Wahrendorff
Details
Tests the "virtual printing" (2.16 MB, application/zip)
2014-02-10 12:23 UTC, Wahrendorff
Details
PDF_Output_showing_degeneration.zip (277.42 KB, application/x-zip-compressed)
2017-10-31 13:17 UTC, Jan-Oliver Lustig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wahrendorff 2013-12-20 15:37:03 UTC
Created attachment 91043 [details]
Sample Eclipse project reproducing the error under windows

Problem description: 

We are using LibreOffice as a server for PDF generation. We load a "template" (Which is a regular .odt file), do some things with it and save it to pdf format.

When doing this under Windows, the PDF-Files Layout gets corrupted after some repeats. With more complex layouted files, this problem occures earlier, when using some simple styled document, it takes a bit longer to occure. 

This is happening with Libre- and OpenOffice. We tested Versions from 3.5 up to 4.2, the error is the same in all Versions.

This error does not occure on Linux Systems, which use the CUPS-PDF-Printer for this task. Therefore I blame the internal PDF Converter in the Windows Version as beeing the source of this error.

Steps to reproduce:
Prerequisites: JRE and Eclipse 

1. Unpack PdfTest.zip
2. Start Eclipse
3. "Import..." > Existing project into Workspace
4. Select unpacked PdfTest folder
5. run programm as Java Application
6. check PDF Files beginning with "template" under C:\Users\Username\AppData\Temp\ for corrupt Layout.
7. If no files are corrupt, run the programm again, without restarting soffice.bin, check again.

Current behavior:
After 200 ~ 2000 generated PDF files, the Layout of the PDF files "degenerates". In the test file this means the bold and italic Formating is missing, Arial Font becomes Times New Roman. 

Expected behavior:
Layout should not be degenerating when producing large amounts of PDF files.
              
Operating System: Windows 7
Version: 4.1.0.4 release
Comment 1 Jean-Baptiste Faure 2013-12-21 16:50:13 UTC
What about if:
1/ on Linux: instead of using cups/pdf (virtual printing) you use pdf export?
2/ on MS-Windows: instead of using pdf export you use a virtual pdf printer?

Best regards. JBF
Comment 2 Wahrendorff 2014-02-03 08:54:27 UTC
Answer 1: Under Linux neither with PDF-Export nor PDF-Printing any degeneration of the generated layout is observable after 2000 repetitions. 

Please see the attached JUnit-Test. For testing the "virtual printing" please use the VirtualPdfTest-Project/Zip and place the name of the virtual printer in L. 629 in OOoHelper.java. 

The test writes into the default cups-pdf work-directory, for me its /home/<user>/PDF. This test differs form the other in that way, that the output file is overwritten. The last written output-file is the result after the 2000th run.

Answer 2: Under MS-Windows the problem does *not* occur while printing 2000 times to PDFCreator (pdfforge) virtual printer with default PDF configuration. The resulting PDF looks good.
Comment 3 Wahrendorff 2014-02-03 08:57:01 UTC
Created attachment 93264 [details]
Tests the "virtual printing"

Tests the "virtual printing"
Comment 4 Jean-Baptiste Faure 2014-02-09 13:44:53 UTC
Set back status to UNCONFIRMED.
Can't test further because I do not have Eclipse installed and I do not want install it.

Best regards. JBF
Comment 5 Wahrendorff 2014-02-10 12:23:13 UTC
Created attachment 93766 [details]
Tests the "virtual printing"
Comment 6 Wahrendorff 2014-02-10 12:25:22 UTC
Please extract the content of the VirtualPdfPrinter.zip into a folder.
After the exctraction run VirtualPdfTest.jar.
Comment 7 Wahrendorff 2014-06-19 08:43:55 UTC
The problem is still present and important to us.
Comment 8 Buovjaga 2015-01-31 09:39:07 UTC
Reproduced with attachment 91043 [details].
At around 1200, "the bold and italic Formating is missing, Arial Font becomes Times New Roman."

Eclipse Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600

Win 7 Pro 64-bit, had these installed: LibO Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7

Version: 4.5.0.0.alpha0+
Build ID: 309574394bd4ae3e9e10e5ff0d64bdd7bbbc8b83
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-29_23:44:46

Eclipse used JRE 1.8, even though I also had 1.7 and had 1.7 defined in LibO options.
Comment 9 Robinson Tryon (qubit) 2015-12-03 11:04:41 UTC
Converting Whiteboard tags to Keywords: filter:pdf
Comment 10 QA Administrators 2017-10-30 08:31:31 UTC Comment hidden (obsolete)
Comment 11 Jan-Oliver Lustig 2017-10-31 13:17:51 UTC
Created attachment 137406 [details]
PDF_Output_showing_degeneration.zip

I was just able to reproduce the issue under Windows 8.1 (6.3.9600) using LibreOffice 5.3.6.1 (686f202eff87ef707079aeb7f485847613344eb7)

The zip Archive contains some of the produced 2000 PDF files:
* 0001    (looks as it should)
* 1218    (still looks good to me)
* 1219   !(2nd line has changed from Times to Arial) 
* 1220   !(2nd and 4th line reduced to font-boxes)
* 1221   !   "
* 2000   !   "
Comment 12 QA Administrators 2018-11-01 03:52:39 UTC Comment hidden (obsolete)
Comment 13 Jan-Oliver Lustig 2018-11-13 16:01:44 UTC
I was just able to reproduce the issue under Windows 8.1 using LibreOffice Version: 6.0.6.2
Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77

The results are nearly identical to those in Comment #11 with the first obviously broken Dokument around #1242.