The customer reports: In attachment, 2 Duotone images made in PhotoShop, and saved once in EPS and once in PDF. Both files have 1 Spot Color, "PANTONE Orange 021C" (you can check in Acrobat). The command line I'm using: /bin/gs -sDEVICE=tiffsep -sOutputFile=a.tif -r72 -DBufferSpace=10000000 -dNOPSICC -dNOPAUSE -dEPSCrop -f $1 -c quit Normally, what should happen, for both files, is that gs should produce an additional plate, "a.s0.tif", for the Spot, containing a grayscale gradation for the Orange part. And the main TIFF file (a.tif) should be a gradation between black and orange. But what happens is: - with the PDF: no additional plate is produced, and the main TIFF is grey. It seems the spot part is just discarded. - with the EPS: the additional plate is produced, but it's empty. The main TIFF is correct. Note also that when you switch to tiff32nc with the PDF file, you have a correct rendering. I've tried with 8.71, 8.64 and 8.60, and got exactly the same behavior for all versions. I've verified that it continues to happen with head (r11299).
Verified that we are missing the orange plate. Digging deeper to see why.
This is an indexed image whose base space is DeviceN. We end up using image_render_mono like expected. All is fine until we perform the remap concretization of the DeviceN colors (no alternate space is used since we are going to tiffsep). At this stage, we end up in cmap_devicen_direct. It obtains the number of components from the dev that it was passed. In this particular case, it is a clipper device. Unfortunately, the clipper device seems to think we only have 4 components present as opposed to the 5 that we need ( CMYK + 1 spot). Digging further to see when the clipper device is initialized and why its color_info is not correct....
After looking at this a bit closer, the problem is not with the clip device but the issue is that the deviceparams are not updated before the image is rendered. zputdeviceparams which updates the colorinfo in devn_put_params does not occur until after we already have already run image_render_mono so we end up having the incorrect color information in the device. I believe this may involve some interpreter issues since that is where putdeviceparams is called from.
Assigning to Alex, since this appears to me to be an issue with respect to when zputdeviceparams is called from the interpreter. It should occur before we ever get to image_render_mono so that the proper color information is set up in the device before we start rendering the duo-tone image. I would think it would have been set up when the DeviceN color space was installed.
We've received another file from the same customer which I believe is the same issue. I've placed the file on spectre.ghostscript.com in /home/support/691335/
Created attachment 7555 [details] Patch for PDF case The PDF case turned out to be quite simple. PDF file provides detailed data about all color separations. The patch fixes a bug in /Indexed color space handling and adds scanning of Image XObjects for color names. The EPS case is less clear. The sample file has %%DocumentCustomColors comment mut DSC comments are often missing or incorrect.
The patch has been committed as a rev. e895d3aae94fa6ca1c53c4e7a47f5894ee3c5943 Many regression test samples now have more separations on psdcmyk device.
Created attachment 7558 [details] Experimental patch for EPS case The problem with EPS is, mostly, caused by the EPS file. The file checks whether the separations are available and uses a different color space when they are not. The proposed patch checks tor tiffsep output device and confirms any duotone separations.
Created attachment 7594 [details] Patch for EPS case This patch enables proper separation support in for Photoshop EPS files or PS files that include the EPS files. The patch uses spot color information from DSC comments that must be located at the beginning of the file. Comments at the end of the file have no effect. Currently, the patch is enabled on the devices that produce separations: psdcmyk and tiffsep.
Created attachment 7595 [details] Improved patch for the EPS case. This is an improved version of the EPS patch. It uses more reliable way of detecting devices that can produce many separations.
The improved patch has been committed as a rev. 28ab2c1fafd763c7ab1074c91bf217bbbc871fe7