Bug 692612 - ps2write Problem with indexed CMYK Colorspace images
Summary: ps2write Problem with indexed CMYK Colorspace images
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Writer (show other bugs)
Version: 9.04
Hardware: PC Windows XP
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-18 12:10 UTC by gstest311
Modified: 2011-11-25 16:03 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
ps testfile for reproducing the error with ps2ps2.bat (87.52 KB, application/postscript)
2011-10-18 12:10 UTC, gstest311
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gstest311 2011-10-18 12:10:44 UTC
Created attachment 8018 [details]
ps testfile for reproducing the error with ps2ps2.bat 

Hello,
i have a problem with converting a pdf file created with Adobe InDesign CS5
to postscript using pdf2ps.bat. At least one of the imagedata values of a indexed
CMYK image is assigned to a wrong color value of the color look up table.
In order to generate a simple testfile for this bug i have converted the pdf to a postcript file, using XPDF (XPDF have no problems with this kind of images).
Then i have stripped down the resulting ps file to the image which produces the error.
I have attached this file to this bug report. You can reproduce the error with this testfile using ps2ps2.bat and the current Ghostscript release 9.04. It seems that a value near 0 (->white) is assigned to the greatest (darkest) value of the color table.
If i use Ghostcript 8.71 with the ps2write device the image is converted correctly.
Comment 1 Alex Cherepanov 2011-10-27 13:18:36 UTC
Yes, the index table in the generated PS file is corrupted.
Manually fixing the table restores the picture.
Comment 2 Ken Sharp 2011-11-25 16:03:47 UTC
The problem is simply Indexed colour spaces, not specific to CMYK. The Indexed lookup table is created internally as an escaped string, but when written to file it is converted back to a Hex string. The conversion was not accounting for the 'special' escaped characters (\n, \r, \t, \f, \b)

Fixed in commit: 979f2182372d924ce69f8d904e87173107209b6b