Download it now!
Bug 125704 - PDF export of embedded PDF outputs PDF that looks different
Summary: PDF export of embedded PDF outputs PDF that looks different
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-06-05 10:48 UTC by philipp.kloke
Modified: 2019-06-05 14:36 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Input PDF (2.68 MB, application/pdf)
2019-06-05 10:49 UTC, philipp.kloke
Details
.odt file (4.56 MB, application/vnd.oasis.opendocument.text)
2019-06-05 10:50 UTC, philipp.kloke
Details
Output PDF (2.41 MB, application/pdf)
2019-06-05 10:51 UTC, philipp.kloke
Details
Screenshot (476.76 KB, image/png)
2019-06-05 10:51 UTC, philipp.kloke
Details
clip from Save As Export (lossless) from Draw 6.4.0 alpha0 (904.28 KB, image/png)
2019-06-05 13:49 UTC, V Stuart Foote
Details
clip from original Input PDF (927.10 KB, image/png)
2019-06-05 13:51 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description philipp.kloke 2019-06-05 10:48:57 UTC
Description:
Given a .odt file (see attachment) with a PDF file inside (see attachement Input.pdf). If this is exported to PDF from LO (Output.pdf), the result looks wrong (while it is shown correctly in LibreOffice itself). In the attachement, there is also a screenshot with a comparison.

Steps to Reproduce:
1. Open attached .odt file
2. Export (Not print!) to PDF
3. Open result in PDF viewer and compare

Actual Results:
Thick green lines in the resulting PDF file

Expected Results:
PDF should look as it is shown in LO


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 philipp.kloke 2019-06-05 10:49:51 UTC
Created attachment 151926 [details]
Input PDF
Comment 2 philipp.kloke 2019-06-05 10:50:27 UTC
Created attachment 151927 [details]
.odt file
Comment 3 philipp.kloke 2019-06-05 10:51:08 UTC
Created attachment 151928 [details]
Output PDF
Comment 4 philipp.kloke 2019-06-05 10:51:40 UTC
Created attachment 151929 [details]
Screenshot
Comment 5 philipp.kloke 2019-06-05 11:21:31 UTC
As suggested in IRC, here is information from Help->About:

Version: 6.2.4.2 (x64)
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 6 V Stuart Foote 2019-06-05 13:49:10 UTC
Created attachment 151940 [details]
clip from Save As Export (lossless) from Draw 6.4.0 alpha0

Confirmed on Windows 10 Home 64-bit en-US (1809) with
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 88f48b51f3cf25c78db278499d46d4913ab442ed
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Adobe based PDF view/edit chokes on the Chromium [pdfium based] source input or the LO exported PDF

MS Edge PDF renderer shows just some of the base shapes, but then stops without drawing any layers.

Only the pdfium based Chrome PDF renderer [Version 75.0.3770.80 (Official Build) (64-bit)] renders the source input.pdf and the LibreOffice rendered PDF.

Attaching a screen clip from Chrome viewing of LO Save As Export (lossless) from a Draw session set to full size of source PDF. And the same clip area for the original input PDF.
Comment 7 V Stuart Foote 2019-06-05 13:51:22 UTC
Created attachment 151941 [details]
clip from original Input PDF

The original PDF opened in Chrome Version 75.0.3770.80 (Official Build) (64-bit), so pdfium based rendering.
Comment 8 V Stuart Foote 2019-06-05 14:02:37 UTC
Performed a round trip of Input PDF (attachment 151926 [details]) taken through insertion onto Draw document canvas and then save-as exported (lossless) back to PDF.

It shows the LO pdfium export with polygon fill, transparency and z-order layering of draw elements.

Most obvious is the bold green line which should be underneath transparent dashed lines.

Had thought mishandling of transparency was on import parsing as bug 108726 but as we are reparsing the orginal PDF stream for the export--seems to be internal against the pdfium filter?
Comment 9 V Stuart Foote 2019-06-05 14:12:24 UTC
(In reply to V Stuart Foote from comment #8)
> It shows the LO pdfium

s/It shows the/It shows issues with the
Comment 10 V Stuart Foote 2019-06-05 14:36:18 UTC
adjusting component...