Summary: | Overprint/Text Knockout | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Robin Watts <robin.watts> |
Component: | Color | Assignee: | Ray Johnston <ray.johnston> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | michael.vrhel, sphinx.pinastri |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: |
simplified
preliminary_fix.patch |
Description
Robin Watts
2017-02-24 12:38:19 UTC
Created attachment 13429 [details]
simplified
Simplified file
The text fills occur with RGB values and overprint is on, with the softlight blend mode. Of course overprint with RGB fills make no sense but we go ahead and set the blend mode to overprint compatible since we are going out to a CMYK device (e.g. tiff32nc works), overprint is true and we have transparency. If I don't let the interpreter change the blend mode, we match Adobe. I believe we need to look at what the current color fill type is in the interpreter and not change the blend mode if the fills are RGB or Gray types. Pushing this to Ray to have a look as he did the interpreter work for CompatibleOverprint blend mode. By the way this does not need to run in clist mode to see the issue. Created attachment 13431 [details]
preliminary_fix.patch
I'm not sure what the test file is supposed to look like, but I see a very
slight color difference with the patch that doesn't result in the special
"CompatibleOverprint" handling that pushes an extra group.
Note that if there are more colorspaces types that don't need the special
handling we can add them.
One question is, do we need to check for an Indexed colorspace base space?
(if I had to guess, I would say "yes, we should").
Also if there are fewer colorspaces that _do_ need the special handling, it
would be easy to change the logic for that.
Ray's patch was incorporated (with some changes) into the commit 009d44b855dcda9d0d9ecf5ca20944504648eebe . This bug can be closed now. Thanks for checking this, Peter. |