See https://bugs.launchpad.net/ubuntu/+source/cups/+bug/196009 The user tries to print an invoice where the company logo is a GIF with transparent background. He generated the file (attached) with GNU Cash. The PDF file displays correctly with evince and Adobe Reader. Ghostscript displays it with the background of the GIF being black. The black background occurs for all output devices, especially also for all printer drivers. He observed the problem with the Ghostscript 8.63 which comes with Intrepid. To exclude that the problem is caused by Ubuntu patches or already fixed during the further development of Ghostscript I have tried it also with the newest SVN state and the problem still occurs.
Created attachment 4631 [details] invoice-with-gif.pdf PDF generated by GNU Cash, with embedded GIF
Created attachment 4632 [details] invoice-with-gif-2.pdf invoice-with-gif.pdf, processed by the pdftopdf CUPS filter
The document draws a rectangle with a Pattern colorspace consisting of a DeviceRGB image with a DeviceGray softmask. The problem occurs with the smask_work branch r9217.
Created attachment 4633 [details] invoice-reduced.pdf Reduced test file based on invoice-with-gif-2.pdf, including just the problem pattern.
Since this is probably an SMask issue, assigning to Michael
Adding the reduced file to my testing files for the soft mask branch.
I don't believe this is a smask transparency issue. When I ran the reduced file, the pdf14 device is not even installed and the rendering is coming out wrong. My guess is that this is an image problem. This should probably be assigned to Alex.
The image in the PDF file does contain an SMask: 6 0 obj << /ColorSpace /DeviceRGB /Subtype /Image /Length 133860 /Width 460 /Type /XObject /SMask 7 0 R /BitsPerComponent 8 /Height 97 >> stream 7 0 obj << /ColorSpace /DeviceGray /Subtype /Image /Length 44621 /Width 460 /Type /XObject /BitsPerComponent 8 /Height 97 >> The output is, bizarrely, drawn as a Pattern colour space, using an image. This space is then used to fill a rectangle. The graphics state sets both CA and ca to 1 and this does appear to affect the way the image is drawn. If I set them to 0, then the output (in Acrobat) is blank. I'm guessing the black background is some artifact of the way the opacity is handled, this may be done outside pdf14 though. No idea why the Smask for the image in the Pattern colour space is not activating the pdf14 code.
Problem still persists with Ghostscript 8.64 SVN HEAD.
This is not a regression from 8.63, so I don't consider it release critical. Unfortunately it looks unlikely to be fixed for 8.64.
The pdf_main.ps doesn't properly identify this file as using transparency. The 'resourceusestransparency' doesn't drill down into Pattern entries which is where /R1 is listed which then has the /x11 named object which is the image with an SMask. The following is a hand formatted excerpt from the beginning of the PDF file: ================================================================================ 1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj 2 0 obj << /Count 1 /Kids[3 0 R] /Type /Pages >> endobj 3 0 obj << /MediaBox [0 0 612 792] /TrimBox [0 0 612 792] /Parent 2 0 R /Type /Page /Resources<< /ExtGState<< /R0 <</CA 1/ca 1>> >> /ProcSet[/PDF] /Pattern<< /R1 4 0 R>> >> /Contents 7 0 R >> endobj 4 0 obj << /TilingType 1 /YStep 3365 /Resources<< /XObject<< /x11 20 0 R>> >> /BBox [0 0 460 97] /PaintType 1 /XStep 3365 /Type /Pattern /PatternType 1 /Matrix[0.5 0 0 0.5 186.01 739.49] /Length 33 >> stream q 460 0 0 97 0 0 cm /x11 Do Q endstream endobj 7 0 obj <</Length 62>> stream /Pattern cs /R1 scn /R0 gs 0 0 611.999983 791.999983 re f endstream endobj 20 0 obj << /Subtype /Image /BitsPerComponent 8 /Width 460 /Type /XObject /ColorSpace /DeviceRGB /SMask 22 0 R /Length 133860 /Height 97 >> stream ... ============================================================================== Assigning to Alex to fix the PDF interpreter (pdf_main.ps), then if it still doesn't look right please assign to Michael.
The following 'patch' hack forces the 'usestransparency' true when the Pattern is seen in the resources. With this, the pdf14 device _IS_ installed and I see begin/end transparency_mask and begin/end transparency_group, etc. but the output is till wrong. I am cc'ing Michael in so he can start on the next problem (while Alex is fixing the PDF interpreter). *** Resource/Init/pdf_main.ps Thu Jan 15 09:22:54 2009 --- ./pdf_main.ps Tue Feb 3 09:49:46 2009 *************** *** 1661,1666 **** --- 1661,1667 ---- } ifelse } forall { pop //true exit } if } if + dup /Pattern knownoget { pop //true exch pop exit } if 2 copy //false put % Visited but not in the current chain. pop //false exit } loop
Created attachment 4781 [details] pattern_trensparency.patch The detection of Patterns that use transparency is done -- next is the handling in the actual pattern_accum. This patch is against the smask_work branch and I may commit it there soon. I will assign it this bug to myself since other than review, Alex doesn't need to do anything. Alex, feel free to comment on the Resource/Init files.
The patch is quite easy to read. I have no objections.
Created attachment 5174 [details] pdf-of-printing-png-with-transparent-background-from-eog.pdf This PDF file is the output when printing a PNF with transparent background from eog. On Ubuntu this gets fed into Ghostscript, run with a printer driver to print on non-PostScript printers. On the printout a black background occurs. For reproducing the bug it is enough to display the PDF on the screen with Ghostscript. See https://bugs.launchpad.net/bugs/362641
Tested with SVN HEAD (will be released as 8.70 next week) and there the problem does not occur any more (I tested by converting to PNG with "png16m").