Ghostscript tiffsep device (and possibly others) are rendering the attached PDF incorrectly. The "Varnish" colorant is duplicated onto every separation and is overprinting it, obscuring everything. Acrobat renders this properly, as does Creo Prinergy VPS output device.
Created attachment 4074 [details] bad raster output from tiffsep
Created attachment 4075 [details] PDF source file that gives the problem
Comment on attachment 4075 [details] PDF source file that gives the problem Private-ing the attachments, proprietary data.
This is a conflict between transparency and overprint features in Ghostscript. Running the file with -dNOTRANSPARENCY fixes overprint but breaks the transparency.
Alex, is this an inherent problem, or a bug that can be fixed easily?
Created attachment 4271 [details] 00540WBB200.pdf Second PDF Source file
Created attachment 4272 [details] 00540WBB200-tiffsep.pdf tiffsep produced from file of same name
After taking a look at 00540WBB200.pdf I disagree with Alex's comment about the problem being a conflict between transparency and overprint. While that is a complex issue, it does not seem to be the issue here. The only effective way to achieve proper softcopy preview of overprinting separations would be to have an intermediate separation output device to which the separations are stored. These would then be propely "merged" for the soft copy preview, at the end. I am adding Ken onto this, since he and I had a discussion about this recently via email. I am a little puzzled about the output of the tiffsep device for 00540WBB200.pdf. The separations do not look exactly correct to me. For example, the orange circle color is clear in the separation stuck in what is called the Magenta separation but the "Western Beef" orange color is no where to be found. I will take a closer look. It would be nice to have a smaller file. This thing has over 700 objects.
Re Michael's comment: "The only effective way to achieve proper softcopy preview of overprinting separations would be to have an intermediate separation output device to which the separations are stored." The tiffsep device is supposed to be exactly this type of device -- the CMYK composite image is composed from the separate (separations + CMYK) planes when the page is emitted. Errors on individual separations WILL be reflected in the CMYK composite output, but since we use the 'tint transform' info from the Separation data in order to perform the 'merge' of the separation layers onto the CMYK planes, problems in the tint transform can also cause problems in the CMYK 'proof'. Also the 'merge' is rather simplistic, assuming subtractive inks, so we make no attempt (in tiffsep) to account for the 'opacity' or order of the inks.
Thanks Ray, I was wondering about that. In this particular case the merged image is way off. The issue is likely in the merge process and the assumptions that are made. I will make a simple (smaller) example to play around with.
Created attachment 4331 [details] MySepTestFile.pdf A simple example of using spot colors, some with overprint and with some being "transparent" inks (e.g. like an overcoat). Our tiffsep device gives very odd output for this file.
Created attachment 4332 [details] AR7_MySepTestFile.png Screen capture from Acrobat Reader 7
Created attachment 4333 [details] GS_tiffsep_composited_MySepTestFile.tif Ghostscript tiffsep composite output. The biggest difference I see is that the "PANTONE Red 032 C" color is 'brighter' with GS. This does result in the overprint areas also being different. Adobe may have a different idea about what this color is supposed to be -- we are just using the tint transform info. The "PANTONE 8723 C" color is also off slightly, and the area overprinted with the "TOYO 0187" is noticeably different. Overall, however, I'm not sure I'd classify this as "very odd output". Note that the view of the composited TIFF looks the same as using the display device with -dDisplayFormat=16#a0800
That is right, Adobe has a Pantone library that is probably more accurate than the tint transforms PDF creators put into the file. I don't believe anyone is nitpicking over color here, we are talking about entire parts of the file not printing at all.
I've confirmed the original issue for this bug is that the "Varnish" was overprinting every other separation. I will update the customer to the SVN version to confirm it's still present.
The problem with the original file (attachment #2 [details]) still happens, but when I run -dNOTRANSPARENCY seems to overprint correctly even though the 'Varnish' separation still has the same content. Seems that the transparency rendering isn't working with the overprint compositor properly. As far as I can tell, the MySepTestFile.pdf is a red herring, but possibly adding transparency to it would show the error with a simple test file.
Created attachment 4334 [details] MySepTestFile.pdf OK. I ignore all the above comments by me. I had an issue with my Visual Studio solution. The issue is with overprint combined with transparency. The attached file suffers from the issue. The white and yellow regions are set to overprint. With the presence of a cyan fill with opacity under these over print fills we end up NOT doing overprint for those colors. So, as Alex had said, there is an issue when doing overprint with transparency. Using this example, I will see if I can figure out where things are going wrong.
Created attachment 4335 [details] AR_Output.jpg Here is the AR output, with overprint preview showing the use of overprint for the white and yellow.
Created attachment 4336 [details] SepOutput_RedSpot.tif Here is the separation output image for the red spot color. Note that overprint of the yellow and white spot colors blew away part of red fill.
*** Bug 688952 has been marked as a duplicate of this bug. ***
Has any progress been made?
I am working on transparency issues now and this is one of them. Now that I have a simple example, it should be straight forward to figure out the issue.
Customer again asked about this issue. It's costing them hundreds of man hours per week to work around this.
Looked into this and currently when there is a transparency present we install the pdf14 device. This device has no overprint support. There are two possible solutions. One would be to add overprint support to the pdf14 device. The other would be to somehow make use of the overprint compositer gsovrc.c. It currently is not installed when we already have the pdf14 compositer. When we do -dNOTRANSPARENCY it is installed and overprint works properly. My preference would be to add overprint directly into the pdf14 code, likely by redefining the rectfill when overprint occurs. Looking for input on this....
Fixed with r9331.