When printing via the (now default) pdf print engine under Linux, objects with transparency enabled on a set background color are always printed as having a transparent black background. I have only tested this behavior with Writer frames and Draw shapes, but assume it affects any object with similar background properties. Steps to reproduce 1. Create a new writer document 2. Insert -> Frame 3. Background tab 4. Change background color to any color (white in my example document) 5. Change transparency to 50% 6. OK 7. Print Expected Printed document's frame should print as it looks on-screen. The background color should be the same color as selected, just transparent. Actual The background color of the frame is transparent, but appears to ignore the color selection. This leads to a transparent dark gray background, even when the color is set to a light color, like white. Note that this only seems to affect printing via the pdf print engine under Linux. Printing via postscript avoids this issue, but bug 67802 keeps us from using postscript in LO 4.1.x. I was able to reproduce this behavior in all libreoffice versions I've had access to under Linux from 4.1.2 back to 3.5.7 using 64bit RHEL6, 32bit Fedora 17, and 64bit Arch Linux(updated as of 10/31/13). I assume it affects all versions of LO going back to release. Since I can only test it back to 3.5.7, I'll mark that as the version. I wasn't able to reproduce this behavior under MS Windows, so I assume that it just affects printing from Linux. Then again, I'm not sure what print engine is being used as the printing system is obviously quite different.
After MANY more tests printing from various environments to various CUPS servers. I no longer think LibreOffice is the primary cause of this bug. Current cups server rhel6 cups 1.4.2 ghostscript 8.70 New test cups server Arch Linux cups 1.7.0 ghostscript 9.10 I set up the same networked postscript printer using the settings/ppd on both cups servers. I was then able to use libreoffice 4.1.2 on a system exhibiting the bug to "Print to file," which generated a pdf. After that, I printed the generated pdf using lpr to each printer. On the old cups server, it failed in the way I described above, but everything printed as it should on the new cups server. While researching this problem, it appears that there have been quite a few bugfixes to ghostscript to handle CUPS's transition from postscript to PDF-based printing workflow in 1.6.x. This issue was likely fixed with one of those changes. I'll mark this as RESOLVED, but I'm sure this and other pdf print mode bugs will still affect older print servers.
I'm resurrecting this bug and setting the status back to UNCONFIRMED. I might have been too hasty in closing it before, but I'll leave that decision for someone else. I don't think it is unreasonable to expect to be able to print using the default print method (PDF mode) properly using the current stable versions of RHEL/CentOS/Ubuntu for a print server. As I did in bug 61189, I used VirtualBox to set up a number of standard desktop/server Linux distributions as remote cups servers. I then printed the same sample document from the same environment (LO 4.2.2.1 using 32bit Fedora17) using the various cups servers. Each of these print servers ultimately printed to the same networked printers/copiers using the same ppds. I tested other versions of LibreOffice and other types of printers, but only the cups server seemed to make a difference. I also used my method from comment 1 as another check. I used "print to file" to generate the pdf that would be passed to the print server. I then used "lpr -P PRINTERNAME FILE.PDF" to actually send the job to the cups servers. I received the same results as when printing using LibreOffice. I'll attach both the test file and the generated pdf print job. I tested printing to native cups servers (server and workstation): 64bit RHEL6 (Primary remote CUPS) CUPS 1.4.2 foomatic 4.0.4 32bit Fedora 17 (Workstation local CUPS) CUPS 1.5.4 foomatic-filters 4.0.8 And I used the same virtual cups servers I set up for the other bug report: 32bit CentOS 6.4 CUPS 1.4.2 foomatic 4.0.4 32bit CentOS 6.5 CUPS 1.4.2 foomatic 4.0.4 32bit Arch Linux CUPS 1.7.0 foomatic-filters 4.0.17 32bit Ubuntu 12.04.3 LTS CUPS 1.5.2 foomatic-filters 4.0.16 32bit Ubuntu 12.04.4 LTS (updated) CUPS 1.5.3-0ubuntu8 foomatic-filters 4.0.16 32bit Debian 7 CUPS 1.5.3 foomatic-filters 4.0.17 32bit openSUSE 13.1 CUPS 1.5.4 foomatic-filters 4.0.12 32bit Mageia 3 CUPS 1.5.4 foomatic-filters 4.0.17 The following print servers FAILED to print correctly. 64bit RHEL6 (Primary remote CUPS) 32bit Fedora 17 (Workstation local CUPS) 32bit CentOS 6.4 32bit CentOS 6.5 (Updated to see if anything changed) 32bit Ubuntu 12.04.3 LTS 32bit Ubuntu 12.04.4 LTS (Updated to see if anything changed) And the following print servers processed the job CORRECTLY: 32bit Arch Linux 32bit Debian 7 32bit openSUSE 13.1 32bit Mageia 3 So, it appears that the Fedora/RHEL cups servers showed the bug. Also, Ubuntu 12.04 shows the same bug. I suppose I should submit bug reports to trackers for those distributions. I also plan on testing more up-to-date Fedora/Ubuntu print server environments. Luckily, bug 67802 was fixed, so we're at least able to switch to using postscript again as a work-around.
Created attachment 96863 [details] Example document with transparent white frame
Created attachment 96864 [details] Print job generated from "print to file" using example document. I've attached the file generated from choosing "Print to file" under the Options tab of the print dialog when using the standard pdf print mode. You should be able to lpr this file directly to a printer as a test.
Created attachment 96867 [details] Scan of the resulting print jobs, demonstrating buggy/working print jobs Just to be clear, the first page demonstrates what the bug looks like when printed from RHEL6. The second page demonstrates how it should print, as it does from Debian7.
I just found the official bug report for this, so I'll mark this as a duplicate. *** This bug has been marked as a duplicate of bug 44135 ***