Summary: | Incorrect rendering of colorant onto every separation. | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Jason Giglio <gigs> |
Component: | X Display Driver | Assignee: | Michael Vrhel <michael.vrhel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ken.sharp, marcos.woehrmann |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
MySepTestFile.pdf
AR7_MySepTestFile.png GS_tiffsep_composited_MySepTestFile.tif MySepTestFile.pdf AR_Output.jpg SepOutput_RedSpot.tif |
Description
Jason Giglio
2008-06-02 10:42:57 UTC
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. |