Using the head GS (date 25-nov-2009) and all versions before rendering of transparencies with the tiffsep device is problematic. Lot's of PDFs will be rendered incorrectly or even crash the interpreter. A sample PDF file will be attached to this bug. It shows an incorrectly rendered transparency. The used command line is: gswin32.exe -sDEVICE=tiffsep -sOutputFile=test871-page%d.tif -r100x100 Gold-Zusammensetzung.pdf
Created attachment 5716 [details] file which displays the error(s)
I've made several recent changes to this device, so I will investigate this.
A customer has reported this issue as well. I've added their customer number and increased the priority of this bug. I'll attach the files they are having problems with.
Created attachment 5973 [details] BANDOS_d.pdf
Created attachment 5974 [details] overovertrans1punt7.pdf
This works in the HEAD rev (11480) but fails in rev 11305 (last rev before the massive ICC branch merge). This will make tracking down a patch for 8.71 quite difficult. This is probably in Michael's area since it seems to be a transparency and/or overprint color issue (and he obviously fixed it somehow during the ICC branch development).
Moving to GS 9.0 would be optimal since the ICC branch is faster and fixed a lot of rendering issues but checking out rev 11305 to review issue.
I have a simple patch to fix this, but I want to do a bit more testing before releasing. The fix in the icc branch occurred when the soft mask base group color space was set to always be gray since the soft mask data must end up as a single channel luminance component anyway. This saved us a conversion step on the final buffer. A similar thing can be done with with pre-icc merge code, which is what will be contained in the patch. Should have something in the next day or two.
Created attachment 6434 [details] Patch for transparency sep device problem for code prior to icc merge. Patch for transparency sep device problem for code prior to icc merge. We force the base space for the soft mask to always be gray, which must be the case and keeps us from having a final buffer conversion when the soft mask is popped.
The attached patch (made against rev 11480) should take care of the issue. The same patch should be easily applied to 8.71. Closing for support to handle the final details.
Changing customer bugs that have been resolved more than a year ago to closed.