Bug 695863 - False overprint using spot-capable (tiffsep) device
Summary: False overprint using spot-capable (tiffsep) device
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 9.15
Hardware: PC Windows NT
: P2 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-10 10:22 UTC by Zoltán
Modified: 2015-03-16 10:42 UTC (History)
1 user (show)

See Also:
Customer: 885
Word Size: ---

Attachments
Test file (10.71 MB, application/x-zip-compressed)
2015-03-10 10:22 UTC, Zoltán 		Details
Preview of erroneous rendering (2.50 MB, image/jpeg)
2015-03-10 10:24 UTC, Zoltán 		Details
cutdown (deleted)
2015-03-12 12:21 UTC, Michael Vrhel 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Zoltán 2015-03-10 10:22:59 UTC 
Created attachment 11504 [details]
Test file
Comment 1 Zoltán 2015-03-10 10:24:19 UTC 
Created attachment 11505 [details]
Preview of erroneous rendering
Comment 2 Zoltán 2015-03-10 10:33:17 UTC 
Take a look on the attachment: the green arrow shows the place where a non overprinted 5-channel (DeviceN) image appears as overprinted one, moreover, all but the black component are retained, resulting in a white mark as the black plate of the image is empty.

The device I used is tiffsep, no additional swithes are needed, the bug is replicable on any resolutions.

Surprisingly the slightest modification of the test PDF in Adobe Acrobat XI makes the problem disappear so I couldn’t manage to insulate the problematic elements.

Please make an investigation on this problem.
Comment 3 Marcos H. Woehrmann 2015-03-10 12:17:04 UTC 
I've duplicated the problem and like Zoltán can't simplify the file without the problem going away.  I've also verified that it's not a regression.
Comment 4 Michael Vrhel 2015-03-12 12:21:04 UTC 
Created attachment 11513 [details]
cutdown

Here is a cut down.  The file is sensitive to changes.
Comment 5 Michael Vrhel 2015-03-12 13:40:06 UTC 
GS is definitely confused here as Zoltan says it is off doing a fill rect for overprint when drawing the image even though the state should not have overprint on.  Digging further to understand why.
Comment 6 Michael Vrhel 2015-03-12 22:47:44 UTC 
After much digging I now see that when this image is getting processed the graphic state is set with overprint set to 0 which is correct, but the overprint compositor is still active and doing its overprinting in front of the target device.  For some reason it was not disabled.  Will spend more time on this to see why.
Comment 7 Michael Vrhel 2015-03-12 23:17:19 UTC 
The overprint compositor is not getting set idle when the overprint is set to false prior to the image enumeration.  The reason is that the graphic state pop that returns us to the state with the OP set to false has a color setting that is a pattern.   For a pattern color space, gx_set_overprint_Pattern does nothing and simply returns 0.  So the overprint compositor remains active.   I need to think a bit more about this to understand the interaction of patterns and overprinting to make sure I don't break anything.  The solution may be as simple as having gx_set_overprint_Pattern set the overprint compositor to idle, but as we know when dealing with patterns and compositors nothing is usually simple.