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: 2023-06-12 17:27 UTC (History)
3 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...
Comment 11 QA Administrators 2021-06-05 04:26:49 UTC Comment hidden (obsolete)
Comment 12 Roman Kuznetsov 2021-06-09 16:03:17 UTC
still repro in

Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 31ed81ea71a20ec119805f66a42f99b3f80d2dc5
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 13 QA Administrators 2023-06-10 03:14:19 UTC Comment hidden (obsolete)
Comment 14 João Gomes 2023-06-11 23:11:20 UTC
I have the same issue on build 7.5.4.2 (X86_64 / AARCH64), compilation 36ccfdc35048b057fd9854c757a8b67ec53977b6, running on macOS Ventura 13.4 (build 22F66).

This is a critical, basic functionality-breaking bug, and prevents me from doing exporting any of my current PhD documents, which rely heavily on embedded .PDF files, in a timely fashion.
Comment 15 João Gomes 2023-06-12 16:42:34 UTC
I am now trying to isolate exactly on which LOo build the bug starts manifesting itself under macOS Ventura 13.4 build 22F66, so that I may temporarily use the immediately preceding one while you work on a fix (I have a deadline in two days, and the Windows build is giving me all sorts of font-related headaches, which might warrant a separate bug report/feature enhancement request) and also test the first offending one with other macOS versions on VMs. Stay tuned!

Even if this workaround is predictably viable for the next couple of months (I'm already at version 7.3.6.1, and it seems file compatibility is not an issue), it's neither acceptable, as it is a serious WYSIWYG-paradigm-breaking regression, nor workable in the long run, as files produced with newer builds may eventually stop working or rendering correctly on the last working older version.
Comment 16 João Gomes 2023-06-12 16:46:40 UTC
To clarify: I suspect all builds which offer the new dark mode – likely unrelated, but it's an important coincidence, as you'll see – suffer from this bug, and I've always hated working with LOo sticking out as the only app on my system that didn't support it and had blindingly white interface elements.

As such, my plan is to use the latest build available for actual writing work, as it's much less distracting, and resort to the older one just for exporting PDF files.
Comment 17 João Gomes 2023-06-12 17:27:26 UTC
Ok, I found the offending build: when it comes to stable ones, it's version 7.4.0.1, build 43e5fcfbbadd18fccee5a6f42ddd533e40151bcf . But the first one where this bug manifested itself was in 7.4.0.0alpha1, build b871abad383583f02eb49c7e49aeae01f6941072 .

It's sad that I have to stick with version 7.3.7.2, because from these 7.4 builds on kerning was much improved, and being a typographer doing a PhD thesis on typography, I'd like to have the best possible typesetting and am also suspicious about potential layout preservation issues when opening files created with those newer versions on this one.

But not having embedded PDFs export correctly is a complete non-starter, so I know which poison to pick.

Please fix this ASAP! I will be keeping tabs on the pre-release 7.6.x.x builds…