Bug 38065 - PDF Export with LibO Application Colors / Document background color
Summary: PDF Export with LibO Application Colors / Document background color
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 38708 71300 117265 141641 (view as bug list)
Depends on:
Blocks: PDF-Export Options-Dialog-Colors
  Show dependency treegraph
 
Reported: 2011-06-08 00:00 UTC by Marek
Modified: 2021-07-26 03:10 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marek 2011-06-08 00:00:36 UTC
With document color set to any other colour than automatic (white by default) LibreOffice exports the document under DRAW and IMPRESS module to the PDF file with the set document colour while CALC and WRITER do it correctly (ignore the set document colour and export it with white background). While this is not a major bug in some circumstances it might occur annoying.
Comment 1 Rainer Bielefeld Retired 2011-06-27 04:08:11 UTC
*** Bug 38708 has been marked as a duplicate of this bug. ***
Comment 2 Rainer Bielefeld Retired 2011-06-27 04:31:45 UTC
Still [Reproducible] with "LibreOffice 3.4.1RC1 - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]" 

Original report here is concerning Menu 
'Tools > Options > LibO > Appearance > General - Document Background'

Same effect with background from OS theme (reproducible for me with a.m. LibO) is reported in "Bug 38708 - Draw: exporting to PDF inherits window background color".

Printing is ok (I tested with Background from LibO settings).

Also known in OOo, where it seems to be a very old bug, last version where it worked correct for me is OOo 1.1.4.
OOo 3.1.1 And 3.4-dev (obsolete) show same behavior as LibO
Comment 3 Rainer Bielefeld Retired 2011-06-27 05:13:32 UTC
@Thorsten:
Please feel free to reassign if it’s not your area!
Comment 4 Rainer Bielefeld Retired 2011-09-05 06:05:32 UTC
It's hard to understand why an old minor/trivial bug should be listed in "Most Annoying Bugs". That task is for "Major" or more, and mostly new bugs.

I remove it.
Comment 5 rpr 2011-09-06 00:24:03 UTC
Well, for me it is a really annoying bug.

It's a pity that the PDF export, which works correctly in Calc and Writer, has bugs in Draw and Impress. This bug is now 2+ years old and it's time to be fixed.
Comment 6 Reuben Thomas 2011-10-07 14:41:56 UTC
(In reply to comment #4)
> It's hard to understand why an old minor/trivial bug should be listed in "Most
> Annoying Bugs". That task is for "Major" or more, and mostly new bugs.

Then the task should be called "Most annoying major new bugs". This bug is annoying, and the fact that it's old makes it more annoying, not less annoying.
Comment 7 Björn Michaelsen 2011-12-23 13:24:47 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 8 ign_christian 2013-06-17 07:43:26 UTC
Not reproducible while trying PDF Export with Impress & Draw (LO 4.0.4.2 - Win7 32bit)
Comment 9 rpr 2013-06-20 08:51:57 UTC
Also not reproducible with LO Draw 4.0.3.3 on MS Windows 7 64-bit
and with LO Draw 4.1.0.0bata2 on MS Windows XP 32-bit.
Comment 10 Marek 2013-06-28 12:35:29 UTC
I have been able to reproduce the bug in. LO 4.0.4.2 undert both Win XP and Win 7 (draw and impress).
Comment 11 ign_christian 2013-06-28 12:42:59 UTC
Please try resetting user profile:
https://wiki.documentfoundation.org/UserProfile

If after doing that problem still occur, please REOPENED this bug along with your sample file.
Comment 12 João Paulo 2020-02-15 03:14:38 UTC
Running LibreOffice 6.3.4.2 and 6.4.0.2, 64 bits, on Windows 10, I could reproduce this bug on Draw and Impress modules.

Steps to reproduce:

1. Optionally, you can reset your profile folder;
2. Open LibreOffice Draw or LibreOffice Impress;
3. Open Menu Tools, Options, Application Colors;
4. Change the Document Background color to any easily spotted color, (I used blue);
5. Open Menu File, Export As, Export as PDF, select the button Export;
6. Save the exported PDF and open with your PDF reader of choice;
7. Verify that the interface color was exported as if it was the document color.

I am setting this bug as blocking Bug #103378.
Comment 13 V Stuart Foote 2020-02-15 06:07:17 UTC
Confirmed on Windows 10 with 6.4.0.3 and recent master/7.0.0

PDF export from sd (ODG or ODP) incorrectly picks up the UI setting 'Document background' and uses it for page background color.

E.g. a page with no background fill:

  <style:style style:name="dp1" style:family="drawing-page">
   <style:drawing-page-properties draw:background-size="border" draw:fill="none"/>
  </style:style>
  <style:style style:name="dp2" style:family="drawing-page"/>

is incorrectly exported to PDF with a page color pulled from users UI settings. 

It happens when UI is assigned a color anything other than 'Automatic' on Tools -> Options ->  Application Colors. UI color assignments picked up from theme do not affect this--just if set from Tools -> Options.

PDF export filter should not be using a UI setting color value for Draw/Impress document page/slide background. 

The exported PDF page should only receive color when explicit page draw:fill has been set. E.g.

  <style:style style:name="dp1" style:family="drawing-page">
   <style:drawing-page-properties draw:background-size="border" draw:fill="none"/>
  </style:style>
  <style:style style:name="dp2" style:family="drawing-page">
   <style:drawing-page-properties draw:fill="solid" draw:fill-color="#ffffa6"/>

Only an assigned drawing-page-properties draw:fill should be exported (any of the fills [color|gradient|hatching|bitmap|pattern]). Otherwise export to PDF without fill and uncolored.
Comment 14 V Stuart Foote 2020-02-15 06:07:43 UTC
*** Bug 71300 has been marked as a duplicate of this bug. ***
Comment 15 Buovjaga 2020-06-19 15:39:04 UTC
*** Bug 117265 has been marked as a duplicate of this bug. ***
Comment 16 LeroyG 2020-06-19 16:17:36 UTC
Reproducible with: Version: 6.3.6.2 (x86); OS: Windows 6.1;

It bores having to turn off the Document Background color, export, and turn it on again (no more words are needed).

I am happy to use LibreOffice. Thanks.
Comment 17 João Paulo 2020-11-28 05:04:18 UTC
Reproducible with:

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: pt-BR (pt_BR); Interface: pt-BR
Calc: threaded
Comment 18 Julien Nabet 2021-02-28 11:30:29 UTC
On pc Debian x86-64 with master sources updated today, I could still reproduce this.
Let's reset default assignee since Thorsten never popped up here. (but since he hadn't assigned himself, no pb :-))
Comment 19 Gauthier 2021-04-12 10:11:17 UTC
*** Bug 141641 has been marked as a duplicate of this bug. ***
Comment 20 Gauthier 2021-04-12 10:12:18 UTC
Can reproduce this in LO 7.1.2.2

Operating System: KDE neon 5.21
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.80.0
Qt Version: 5.15.2
Kernel Version: 5.11.8-051108-generic
OS Type: 64-bit
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Comment 21 stragu 2021-07-26 03:10:53 UTC
Reproduced with recent master build, in both Draw and Impress:

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: cd2b5168e8ef1cb6e721bc5220421464ed723096
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-21_14:56:23
Calc: threaded