Using gs head (r9931) the regression file 046-01.ps fails with an error when using the psdcmyk device: marcos@i7:[23]% bin/gs -sDEVICE=psdcmyk -o test.tif ./046-01.ps GPL Ghostscript SVN PRE-RELEASE 8.71 (2009-08-01) Copyright (C) 2009 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. StartTestModule. "Pre-test file named 046-01A.PS" Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 3512632 1781590 94065528 92777766 1 done. Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 3545912 1891454 94065528 92779266 1 done. Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 3579192 1996511 94065528 92780646 1 done. StartOneTest. "046-01","currentblackgeneration","Check diverse values return as were set." Ok EndOneTest. StartOneTest. "047-01","currentcacheparams","Verify count and types, but not values returned." Ok EndOneTest. StartOneTest. "048-01","currentcmykcolor","Check diverse values return as were set, initial value is black." Fail: ([.64 .0 .32 .16] gs Separation_Green setcolorspace .8 setcolor cmyk gr) EndOneTest. StartOneTest. "049-01","currentcolor","Check diverse values return as were set, initial value is black." Ok EndOneTest. EndTestModule. The pkmraw device does not produce an error.
These files fail similarly: 050-01.ps 070-01-fixed.ps 070-01.ps 245-01.ps 456-01.ps 470-01.ps 473-01.ps 477-04.ps 477-05.ps Bug689369.pdf Bug689520.pdf Bug689918.pdf Bug690206.pdf pattrans_30.pdf pattrans_45.pdf pattrans_big.pdf pattrans_scaledown.pdf pattrans_scaleup.pdf pattrans_simple.pdf pattrans_solid_nonrect.pdf pattrans_solid_rect.pdf pattrans_translate.pdf
I'm not sure if it's helpful, but on peeves the file Bug690206 at 300 dpi fails with different error: GPL Ghostscript 8.70: ./base/gxclrast.c(1942): Bad op ff band y0 = 528 file pos 4096 buf pos 106/4096 0: df 04 02 09 00 ff 00 00 00 00 10: 00 00 00 30 00 00 00 00 df 01 20: 03 00 0a 00 00 00 df 01 03 02 30: 84 55 55 85 40 00 60 9f 45 00 40: 00 05 00 00 00 00 00 00 80 3f 50: 00 00 80 3f 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 c0 88 40 00 00 80: 00 00 00 20 93 40 00 00 00 00 90: df 01 03 06 03 01 01 00 24 00 100: 00 00 00 00 00 ff 00 00 67 30 110: ac 10 ad 04 02 01 24 00 00 00 120: 00 00 00 ff 00 00 68 5b 24 00 130: 00 00 00 00 00 ff 00 00 67 55 140: c7 24 00 00 00 00 00 00 ff 00 150: 00 66 5c 24 00 00 00 00 00 00 160: ff 00 00 62 40 6c 7f 85 80 55 170: a7 24 00 00 00 00 00 00 ff 00 180: 00 63 53 b7 55 79 24 00 00 00 190: 00 00 00 ff 00 00 64 54 a7 54 200: 89 40 82 80 7e 81 24 00 00 00 210: 00 00 00 ff 00 00 65 5c 5c 40 220: 83 7f 7f 7f 55 79 53 89 40 82 230: 81 7e 81 24 00 00 00 00 00 00 240: ff 00 00 66 5c 24 00 00 00 00 250: 00 00 ff 00 00 67 47 82 80 54 260: 89 24 00 00 00 00 00 00 ff 00 270: 00 68 40 82 80 7e 81 5c 24 00 280: 00 00 00 00 00 ff 00 00 67 5c 290: 24 00 00 00 00 00 00 ff 00 00 300: 66 47 82 80 53 89 55 a7 5c 24 310: 00 00 00 00 00 00 ff 00 00 65 320: 5c 24 00 00 00 00 00 00 ff 00 330: 00 62 40 5a 7f 87 80 24 00 00 340: 00 00 00 00 ff 00 00 61 54 a7 350: 55 79 24 00 00 00 00 00 00 ff 360: 00 00 62 40 82 80 7f 81 24 00 370: 00 00 00 00 00 ff 00 00 61 40 380: 82 7f 7f 7f 55 89 54 97 54 99 390: 54 97 54 99 24 00 00 00 00 00 . . .
I discovered similar problems with the tiffsep device (while testing the tiffsep1 device I am developing). This is a serious clist problem -- I get different errors, sometimes during 'writing' and other times during 'reading' (bad op as reported here). I was testing with the file from bug 689991 and got different results depending on the -dBufferSpace parameter and the resolution. I am investigating already, so assigning to myself (clist problems fall to me anyway).
I've just had a go at reproducing these errors on windows (debug and release builds) and on peeves (release build) and I can't. I think this bug can probably be closed now.
Closing, with Rays blessing.