When the attached PDF file is converted to TIFF via the tiffsep device there is unexpected transparency in a portion of the image (see highlighted screenshot.png attached). This does not occur when the image is converted to tiff24nc and is not visible on the screen or in a TIFF file exported from Acrobat. The command line I'm using for testing: bin/gs -sDEVICE=tiffsep -o test.tif ./221992_v1.pdf
This is the result of a simulated overprint effect. tiffsep device honors requests to every separation used in the PDF file. The overprint flag has full effect, and tint transform functions don't run. tiff32nc device is a RGB device that doesn't support separations. All spot colors get converted to process colors using tint transform functions. The overprint flag is ignored, all objects knock out the background. This effect can be simulated on tiffsep device by redefining "setoverprint" operator as a no-op. gswin32c -dDELAYBIND -r300 -sDEVICE=tiffsep -o nov.tif -c "/setoverprint{==}.bind def .bindnow" -f 221992_v1.pdf The result looks different from the intended image but similar to the pictures produced by Acrobat Reader or non-separation devices. Full Acrobat has overprint preview mode but I don't have Full Acrobat now to test this. Ghostscript works as designed.
(In reply to comment #3) > The result looks different from the intended image but similar to the pictures > produced by Acrobat Reader or non-separation devices. Full Acrobat has > overprint preview mode but I don't have Full Acrobat now to test this. I do have a full copy of Acrobat here, and the result in overprint preview mode is not the same as the apparent Ghostscript output. However, I'm not convinced the Acrobat preview is corfrect either....
This may be related to Bug #692378. In this case what I see is that the Cyan plate is not knocked out by (I believe) one of the objects in a Separation colour space. The red background behind the product name which covers the complex gradient fill knocks out the 's0' plate, but does not knock out the Cyan plate. I'll try and reduce the complexity of the sample file. Note that the Windows display device renders this file correctly. This command line : gswin32 -dDisplayFormat=16#a0800 allows selection of the individual plates and the cyan plate can be see to be correct.
The area showing through from the Cyan plate is erased (on the display device in 16#a0800 mode) when the following is painted: 0.002 0 0 0 k step # 3038 ? 180.830643 283.971588 m step # 3039 ? 180.830643 481.123901 l step # 3040 ? 244.032227 457.542908 l step # 3041 ? 244.740738 457.25531 l step # 3042 ? 244.740738 283.971588 l step # 3043 ? f step # 3044 ? I added debug statements and the FillOverprint is "true" and OPM is 1. Since the color has a non-zero Cyan component, it should be replaced by the above fill (magenta, yellow, black and the other separation colors all have components of 0, so are NOT modified when OPM is 1). I suspect that the tiffsep device is misinterpreting the very small Cyan value as 0. Then OPM 1 painting with a 0 component would leave the layer unchanged.
This is going to require a bit of work to have OPM = 1 handled correctly with these tiny values. Especially with clist rendering, since the small source values like 0.002 are currently gone after we have written to the clist. It may be that we will need to include some additional information about what colorants are *really* non zero in the original source colors and this information will need to make it through the clist.
I think there is actually something truly wrong with overprint for this case as opposed to a small quantized value issue. In my simplified file, the image (which is the star burst like object) is a DeviceN image drawn with Cyan, Pantone 877 C, White and Pantone Reflex Blue C. The Cyan plate from this image has a value of 20% as it passes into the red Crest area so I don't think it is a minimal color value that is the issue there. In that red Crest area there are multiple overprint fills with over print mode set to 1. A fill with white OP=true OPM=true, a fill with CMYK 0 0 0 0 OP=true OPM=true, a fill with Pantone 877 C (value 1.0) OP=true OPM = true, and a fill with CP Red (value 1.0) OP=true OPM true. All of this takes place in the presence of compressed color encoding. Plenty of opportunity for things to go wrong. Will continue digging tomorrow.
I take back my previous comment. If I bump up the tiny value to a slightly larger value, then we do proper overprinting. Working now and a solution for this.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=03b20ec31afa843d5a4bac878568f60abcdea5fc