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
Thick green lines in the resulting PDF file
PDF should look as it is shown in LO
User Profile Reset: No
Created attachment 151926 [details]
Created attachment 151927 [details]
Created attachment 151928 [details]
Created attachment 151929 [details]
As suggested in IRC, here is information from Help->About:
Version: 126.96.36.199 (x64)
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win;
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
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: 188.8.131.52.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
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.
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.
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?
(In reply to V Stuart Foote from comment #8)
> It shows the LO pdfium
s/It shows the/It shows issues with the