| Summary: | Transparent parts of GIFs embedded in PDFs come out black | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Till Kamppeter <till.kamppeter> |
| Component: | PDF Interpreter | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | michael.vrhel |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | https://bugs.launchpad.net/ubuntu/+source/cups/+bug/196009 | ||
| Customer: | Word Size: | --- | |
| Attachments: |
invoice-with-gif.pdf
invoice-with-gif-2.pdf invoice-reduced.pdf pattern_trensparency.patch pdf-of-printing-png-with-transparent-background-from-eog.pdf |
||
|
Description
Till Kamppeter
2008-12-01 11:49:31 UTC
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"). |