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.
*** Bug 38708 has been marked as a duplicate of this bug. ***
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
@Thorsten: Please feel free to reassign if it’s not your area!
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.
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.
(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.
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.
Not reproducible while trying PDF Export with Impress & Draw (LO 4.0.4.2 - Win7 32bit)
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.
I have been able to reproduce the bug in. LO 4.0.4.2 undert both Win XP and Win 7 (draw and impress).
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.
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.
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.
*** Bug 71300 has been marked as a duplicate of this bug. ***
*** Bug 117265 has been marked as a duplicate of this bug. ***
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.
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
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 :-))
*** Bug 141641 has been marked as a duplicate of this bug. ***
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
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
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
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?
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
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
*** Bug 154969 has been marked as a duplicate of this bug. ***
*** Bug 148884 has been marked as a duplicate of this bug. ***
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
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
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
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?
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.
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 ...