Summary: | Issues with duotone images and tiffsep | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | PS Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | 190 | Word Size: | --- |
Attachments: |
Patch for PDF case
Experimental patch for EPS case Patch for EPS case Improved patch for the EPS case. |
Description
Marcos H. Woehrmann
2010-05-22 04:24:16 UTC
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 |