Created attachment 7788 [details] Overprinting Example PDF With the attached PDF "Overprint.pdf", overprinting gives different results depending on wich ICC-Profil is used. When "ps_cmyk.icc" is used as "-sOutputICCProfile", overprinting seems complete of but with the attached "ISOcoated.icc" there are some areas wich are overprinted. Commandline for testing: gswin32.exe ^ -sDEVICE=tiffsep ^ -r150x150 ^ -dUseCropBox ^ -sDefaultCMYKProfile="default_cmyk.icc" ^ -sOutputICCProfile="C:\ISOcoated.icc" ^ -o "C:\Overprint_tiffsep.tif" ^ "c:\Overprint.pdf"
Created attachment 7789 [details] ICC-Profil for the Example
Thomas, I looked this over carefully and this is a rather interesting issue. To obtain proper overprint simulation, while specifying a profile for your device, the only way that ghostscript can currently simulate overprinting is if the default CMYK profile is also the same as the device profile. That is you will need to specify gswin32.exe -sDEVICE=tiffsep -r150x150 -dUseCropBox -sDefaultCMYKProfile="C:\ISOcoated.icc" -sOutputICCProfile="C:\ISOcoated.icc" -o "C:\Overprint_tiffsep.tif" "c:\Overprint.pdf" Consider if we ran with -sDefaultCMYKProfile="default_cmyk.icc" -sOutputICCProfile="C:\ISOcoated.icc". In this case, a source Magenta 100% color is converted from the default_cmyk color space to ISOcoated color space turning Magenta into CMYK of [.3 .93 0 0]. Hence when magenta is drawn it blows away the cyan portion that is already laid down. If we instead have -sDefaultCMYKProfile="C:\ISOcoated.icc" -sOutputICCProfile="C:\ISOcoated.icc" then 100% magenta goes to [0 1 0 0] and the lay down of magenta will not affect the other colors. As specified in the manual overprinting is device specific. The question I have to ask myself is what makes the most sense to do if we did have different profiles for source and destination when doing overprinting. To me there seem to be two approaches. One would be to NOT perform any ICC mappings when we are in an overprint situation. This would amount to having 100% magenta lay down mapped to [0 1 0 0] when we have overprinting but map to [.3 .93 0 0] when we don't have overprinting (this is for the case of the above profiles). To me this does not seem right and is bound to introduce issues where people have done overprint and nonoverprint fills next to one another. The other way that I can think to do this is to, in the above case, have the CMYK overprint of [0.3 0.93 0 0] do an overprint laydown of [0 0.93 0 0]. In this way there will be consistency in the Magenta separation with and without overprint. I would be interested to hear your take on this.
Michael, I agree that the "consistency in the Magenta separation" from this example is a better solution then not performing any ICC mappings. Directly when thinking about Proofing or Simulating another Process. However, I currently can not estimate what will happen with other color combinations. If for example 90 % Magenta have to overprint 50 % Cyan. By the other hand, if the "Overprinting Example" is turned from Vector to an Image, and then converted via -sDefaultCMYKProfile="default_cmyk.icc" ^ -sOutputICCProfile="C:\ISOcoated.icc" ^ the correct colors can be measured. So looking at this tells me, that it could be more complicated then just do a "simpler" laydown. So I will think and play with this a little longer, to get a better expression about it.
Created attachment 7806 [details] Example PDF as an Image
Created attachment 7947 [details] overprint_icc.pdf An example file where we have CMYK fills defined by an ICC profile and overprint enabled.
Looking into this more revealed that AR does not do overprint simulation when the source ICC profile does not match the destination profile. To test this, I created the attached test file that had 2 overlapping fills with CMYK values that were specified by SWOP CMYK values. If the simulation profile in AR matched this profile, then overprinting was properly displayed by AR. If not, then overprinting was not displayed. This makes sense as the overprinted inks really should be in the color space for the target device. Hence, if the source and destination profiles do not match, we will not be showing overprint. Currently testing the commit that ensures we have this behavior.
Fixed (or at least addressed) with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=03b20ec31afa843d5a4bac878568f60abcdea5fc To ensure proper overprinting preview, you must use the same profile for DefaultCMYK as you use for the target CMYK device.
Michael, this works stable now, great. So to have overprinting correct done for different source and destination, it seems that the configuration has to be: -sDefaultCMYKProfile="C:\ISOcoated.icc" -sOutputICCProfile="C:\ISOcoated.icc" -sProofProfile="C:\AnotherCMYK.icc" But the documentation says, that "-sProofProfile" is not fully implemented at this time. Doe you have a time, when this will be integrated?
Thomas, Right. To do this properly, the proofing profile needs to be finished. Since I now have a request for this, I will get moving along on it. I am guessing that I will have it in head in the next month so it would be in the next release which is scheduled for February.