I tried to generate tiffs from PDF containing transparency. I used tiff32nc and tiffsep output devices with v. 8.70. Command lines was: gswin32c.exe -dSAFER -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -r100 -sOutputFile=tiff32nc-8.70.tif 061208_WF_CMYK_PapaJohns_p2_EV0708_406.pdf and gswin32c.exe -dSAFER -dBATCH -dNOPAUSE -sDEVICE=tiffsep -r100 -sOutputFile=tiffsep-8.70.tif 061208_WF_CMYK_PapaJohns_p2_EV0708_406.pdf Output was wrong in both cases. It seems this is regression. Output files from v. 8.64 looks correct
Created attachment 5475 [details] 061208_WF_CMYK_PapaJohns_p2_EV0708_406.pdf This is source file
Created attachment 5476 [details] pj_p2_results.zip This is output files from v. 8.70 and 8.64
Using the current HEAD revision this works OK for me, using both tiff32nc and tiffsep, on Windows (32 bit). Possibly this has been fixed, can you build the latest source and try that ?
I tried to enter to cvs to build HEAD: cvs -z3 -d :pserver:anonymous@cvs.ghostscript.com:/cvs/ghostscript login and pressed enter when it prompts for a password. I have message: cvs [login aborted]: connect to cvs.ghostscript.com(207.238.132.61):2401 failed: Connection refused What is wrong?
>cvs [login aborted]: connect to cvs.ghostscript.com(207.238.132.61):2401 failed: >Connection refused > >What is wrong? Ghostscript uses Subversion, not CVS, the repository is at svn.ghostscript.com
In any case HEAD version is not what we need because this is development, unstable version. Could you send patch for this and only this bug?
Created attachment 5480 [details] patch This bug has been fixed by Michael Vrhel by the rev. 10063 The diff between v. 10062 and v. 10063 is attached. This patch is also available at: http://ghostscript.com/pipermail/gs-cvs/2009-September/009787.html The patch can be applied to v. 8.70 and appears to fix the problem but this combination has not been tested for possible regressions.
I tried your patch. It works with DeviceCMYK color space only (with device tiff32nc). Results with DeviceN color space (tiffsep) are still wrong. I tried HEAD version, it works correctly. We need DeviceN for our purposes. So question is: is it safe to use HEAD version in production environment? If no, please, upload new patch, for DeviceN too.
The problems with tiffsep device get fixed by the following revision: r10062 | mvrhel | 2009-09-09 02:21:02 -0400 (Wed, 09 Sep 2009) | 9 lines A fix for the rendering issue that occurred with bug 689581 after fixing the rangecheck error. This should fix 689581. This patch depend on some earlier work. In my unofficial opinion, HEAD is the best version most of the time. For instance, today's HEAD can has no known problems with JPEG 2000 images. Sometimes, broken code get committed to the head, but pre-commit and post-commit testing ensures that regressions are rare and short-lived.
I found file which is rendered correctly with 8.64 and incorrectly with HEAD. See attachments. Command line is the same
Created attachment 5516 [details] SeaCreatureCrdNOTFLAT.pdf
Created attachment 5517 [details] SeaCreature-tiffsep-HEAD.zip
Created attachment 5518 [details] SeaCreature-tiffsep-8.64.zip
This really ought to be a separate issue, because its a different problem as can be seen by the fact that tiff32nc works correctly. However... The issue seems to be caused by the fact that the PDF file contains a spot colour PANTONE 2478 CVU. Non-separating devices such as tiff32nc which convert the spot colour to device colours work correctly. Checking the spot colour plate its easy to see that the drop shadow is not being reduced to 0 properly. One for Michael I think, so reassigning as such.
Created attachment 5519 [details] bug690816_simple.pdf Here is a simplified version that has the problem.
Fixed with revision 10207.
I tried latest HEAD version (I think this is 10232). It works correctly with file SeaCreatureCrdNOTFLAT.pdf (under the same conditions), but results with file 061208_WF_CMYK_PapaJohns_p2_EV0708_406.pdf are wrong. So I'd like to reopen bug
This seems to work fine with the head.
Changing customer bugs that have been resolved more than a year ago to closed.