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 148884 154969 161185 (view as bug list)
Depends on:
Blocks: PDF-Export Options-Dialog-Colours
  Show dependency treegraph
 
Reported: 2011-06-08 00:00 UTC by Marek
Modified: 2024-05-20 14:11 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:


Attachments
Current and fixed behaviour (48.75 KB, image/png)
2023-11-15 12:57 UTC, Andreas Heinisch
Details

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 Stéphane Guillou (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
Comment 22 Gauthier 2022-10-04 10:53:39 UTC
Can still reproduce this

Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded
Comment 23 Rafael Lima 2023-01-19 18:51:46 UTC
This seems to be working in LO 7.6.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 01ba5828f07458ad20467fef405185ca36291408
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL threaded

And also in LO 7.4.4

Version: 7.4.4.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.4.4-0ubuntu0.22.10.1
Calc: threaded

Can anyone else confirm, please?
Comment 24 rpr 2023-01-20 23:26:10 UTC
Unfortunately, I can still reproduce this bug in LO 7.4.4.2.
If I set Tools > Options > LibreOffice > Application Colours > Document background
then PDF export in Draw and Impress produces a PDF file with the document background colour.

Version: 7.4.4.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Ubuntu package version: 1:7.4.4-0ubuntu0.22.04.1~lo1
Calc: threaded
Comment 25 lol 2023-01-22 14:06:01 UTC
I can also reproduce this bug. Same behavior as described in comment 24. Tested with

Version: 7.4.4.2 (x64) / LibreOffice Community
Build ID: 85569322deea74ec9134968a29af2df5663baa21
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded

and

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 37e3455a13ab5741104bf41d05a80e60a4612682
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
Comment 26 Stéphane Guillou (stragu) 2023-05-09 21:32:05 UTC
*** Bug 154969 has been marked as a duplicate of this bug. ***
Comment 27 Stéphane Guillou (stragu) 2023-05-09 21:36:39 UTC
*** Bug 148884 has been marked as a duplicate of this bug. ***
Comment 28 Dayana James 2023-10-01 12:14:15 UTC
Can't reproduce in LO 24.2.O.O  in Windows (x64) system..

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 506fb766885f147a40f09ffca803b4e31b14b1e1
CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 29 Buovjaga 2023-10-12 07:46:11 UTC
Repro with steps from comment 12

Arch Linux 64-bit, X11
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1f9cd62b67d679da078c50b4b48295918657a70a
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 11 October 2023
Comment 30 Gauthier 2023-11-05 07:54:52 UTC
I can still reproduce this in LO 7.6.2.

Also related is that on as well as for PDF export, the custom application background colour should not be there with Impress in Presentation / Slide Show mode, but it is.

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 4:7.6.2-0ubuntu1
Comment 31 Andreas Heinisch 2023-11-15 12:57:12 UTC
Created attachment 190838 [details]
Current and fixed behaviour

I added a fix for this problem and Imho it is not easy to say which one is the correct one. I set the theme to dark and created two slides. One with a red background the other one is set to automatic.

At the right, there is the export without applying the document color (the text is actually there but it is white) and the below it is exported using the document color.

So, if we fix this problem the user gets unexpected pdf exports. Opinions?
Comment 32 Gauthier 2023-11-15 14:00:43 UTC
Thanks for trying to fix this and reporting on the behaviour.

So it looks like there is an issue that also affects fonts.

Those settings, "Scheme", "Document background" and "Font colour" are the **Application** Colours settings, which either means: 

1. that changes in there should not affect the colours of the actual document (int terms of background, font, etc.) but have only to do with how the docs is displayed in the user interface.

In that case, if you use a Dark scheme, then the background should "appear" black and font white, but unless the user explicit changes the background or font colour in the doc from automatic to something else (in format > page for the background and by choosing manual a font colour), then the doc outputs (PDF, presentation, or just someone opening the same doc on another machine) should have a default white background with black font.

OR

2. These settings relates the default for the actual document in which case they should be relfected in all outputs (PDF, etc) across all LO apps.

In any case there is a bug because neither 1. or 2. are happening. And I reckon this bug report is based on the assumption that the intended function of the Application Colours settings is 1., that is about how things appears in the application rather than on the actual doc.
Comment 33 Jeremy 2024-01-13 13:50:46 UTC
Still reproducible in 7.6.4.1 on Windows 10.

That's quite annoying to be forced to be in light mode to export PDFs ...
Comment 34 V Stuart Foote 2024-05-20 14:03:02 UTC
*** Bug 161185 has been marked as a duplicate of this bug. ***
Comment 35 V Stuart Foote 2024-05-20 14:11:33 UTC
Application color settings bleed over into document style on export to PDF still reproducible 24.2.3.2 and recent 24.8.0.0 builds. 

Seems more of an issue now with the os/DE theme and "Light" and "Dark" AC theme in place as for bug 152184 and bug 153334