Bug 129976 - PDF image loses white background, when presentation is exported to PDF
Summary: PDF image loses white background, when presentation is exported to PDF
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:7.0.0 target:6.4.2
Keywords: bibisected, regression
Depends on:
Blocks: PDF-Insert
  Show dependency treegraph
 
Reported: 2020-01-13 09:31 UTC by Ulrich Windl
Modified: 2020-03-11 07:48 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Test case (Presentation) (150.62 KB, application/vnd.oasis.opendocument.presentation)
2020-01-13 09:31 UTC, Ulrich Windl
Details
Exported Slide (PDF) (98.83 KB, application/pdf)
2020-01-13 09:32 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2020-01-13 09:31:17 UTC
Created attachment 157106 [details]
Test case (Presentation)

Using a dark (black) background to add some plot with a white background (it seems) is displayed correctly on the screen, but not in exported PDF:
In PDF the white background is gone.
Comment 1 Ulrich Windl 2020-01-13 09:32:04 UTC
Created attachment 157107 [details]
Exported Slide (PDF)

This is the PDF export of the test case.
Comment 2 ian 2020-01-13 15:44:23 UTC
Thank you for reporting the bug. I can confirm that the bug is present in recent master builds in Linux and in Windows.

Linux:

Version: 6.5.0.0.alpha0+
Build ID: 8930a7d8b8e649336300d98f0a1f27114ad392ea
CPU threads: 1; OS: Linux 5.0; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master;
Locale: es-ES (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Windows:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 209fc9fd7fa433947af0bf86e210d73fa7f5a045
CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 3 Buovjaga 2020-01-25 21:10:40 UTC
The chart is in fact a PDF image. You can see this by doing right-click - edit with external tool. It opens as .tmp.pdf.

I bibisected with win32-5.4 and got this range:
https://gerrit.libreoffice.org/plugins/gitiles/core/+log/ff8b873936aa72b17309da4bfc2775573a5b1f55..169bd7718264b0e312052757f9bbd2321e1399c2

Looking at the range actually got me to try and figure out the type of the image. It has many commits about "PDF export of PDF image" by Miklos. Bug 107018 bug 107013 and bug 107089 are referenced.

Adding Cc: to Miklos Vajna
Comment 4 Commit Notification 2020-02-04 08:15:56 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7088140dbf1d5e0391c2662f0213018a45620ff9

tdf#129976 PDF export of PDF images: adapt transparency to rendering

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Ulrich Windl 2020-02-04 10:08:26 UTC
One additional thought: As the graphic involved originated from PostScript, I'm wondering: In PostScript there's an implicit white background, so you don't have to fill it with white. That means the background is effectively transparent until you fill it. Seen that way the PDF export would be correct, but the preview with white background would be wrong. Just imagine you would PostScript-print on black paper...
Comment 6 Miklos Vajna 2020-02-04 10:15:18 UTC
Feel free to file a follow-up, non-regression bug about the pdf image transparency; currently the result of a pdf image preview is a non-transparent bitmap, so that's not trivial to fix. (And also it is necessary to consider how to handle existing documents like yours which would turn into something unreadable if we change this.)
Comment 7 Ulrich Windl 2020-02-04 10:37:31 UTC
What I wanted to say is: If the preview in Impress had matched the PDF output, I would have added a white rectangle behind the Graphics.
Comment 8 Commit Notification 2020-02-06 12:01:57 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/c1a79354e6ae96a287095abcfc53f41aa2d43358

tdf#129976 PDF export of PDF images: adapt transparency to rendering

It will be available in 6.4.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Xisco Faulí 2020-02-07 17:15:34 UTC
Verified in

Version: 7.0.0.0.alpha0+
Build ID: c81c383be787ec5f9acbca51f75ea5b28b63c63a
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

@Miklos, thanks for fixing this issue!!
Comment 10 Ulrich Windl 2020-03-11 07:48:32 UTC
Also found a workaround for the original version:
In Linux use "Print" and "Print to file..." using the PDF printer.
The resulting PDF is a bit large, but the content is rendered correctly.