Summary: | Regression: Ghostscript renders only a part of the attached PDF file when using a high resolution | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Till Kamppeter <till.kamppeter> |
Component: | PDF Interpreter | Assignee: | Michael Vrhel <michael.vrhel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | uli_rgbg |
Priority: | P4 | ||
Version: | 9.04 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
Ausgabe-evince.pdf
Simplified sample file |
Description
Till Kamppeter
2011-12-10 23:00:17 UTC
Created attachment 8208 [details]
Simplified sample file
This is a simplified sample file. I've replaced all text with a gray background
and reduced the file to 6 objects.
The problem is also a regression. V. 8.71 renders the file correctly, but vv. 9.00+ don't.
Original file has many layers of forms, patterns, and transparency but the
simplified file has just one big pattern.
This broke with the icc_work branch merge. The "Simplified sample file" (in the sample command lines gs-bug692733.pdf) shows, when correctly rendered, a red rectangle on a gray background. You see this when screen-displaying the file with evince (Poppler), Adobe Reader, or gs (without further options, to default to low-res X screen display). Hi-res Ghostscript output (for printing) is broken. Here the resulting output has a white background. Simplest example command line for the "cups" output device: cat gs-bug692733.pdf | /usr/bin/gs -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r600x600 -dcupsColorSpace=1 -_ > out.raster Same happens for a PNG output device, simplest command line here: cat gs-bug692733.pdf | /usr/bin/gs -sDEVICE=png16m -sstdout=%stderr -sOutputFile=%stdout -r600x600 -_ > out.png You get correct output again with a much lower resolution: cat gs-bug692733.pdf | /usr/bin/gs -sDEVICE=png16m -sstdout=%stderr -sOutputFile=%stdout -r60x60 -_ > out.png This is an interesting one. Here is what I see so far. Just going out to tiff24nc at 300dpi the pattern is a clist and we do not have the gray background in the final output. At 150dpi the pattern is rendered (not clist) and we end up with the gray background in the final output. However, the pattern buffer itself does not have the gray background the only final rendered output does. Will dig further tomorrow to see where and when the gray background is getting put in and why it is not happening in the clist case. I do see the color remap for the gray occur in both cases. Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=83ce7cf6c9252c39e280040b12db1dcfbd8a7cb2 I don't believe this broke with the ICC branch merge but from an incorrect clearing of the pattern when the pattern is a clist. I have tried the fix on GhostScript 9.04 and there it has no effect at all. Do I need additional patches for 9.04? |