[bug-gs] Incorrect rendering for type 1 images when Interpolate==true

[BÍRÓ Zoltán]

Dan,

| The value of depth is limited to 1,2,4,8,16,24,32,40,48,56, and 64.

Drivers.htm says: "For copy_color, the number of bits per pixel is given by
the color_info.depth parameter in the device structure: the legal values are
1, 2, 4, 8, 16, 24, or 32.". Unfortunately -- as you can see in
gdevdbit.c -- gx_default_copy_color() does "respect" this restriction, that
is, only the above mentioned cases are implemented.

| I am unable to reproduce this problem.  I have been testing using the
| spotpsd device with three or four spot colors.
| My difficulty in reproducing the problem may be due to the test file that
| I am using.

I couldn't found spotpsd device so I think it must be the psdcmyk with some
spot colors defined. I've tried the attached test page using the following
command line:

C:\gs\gs8.11\bin\gswin32c.exe -sDEVICE=psdcmyk -r150 -c "<<
/SeparationColorNames [ /Spot1 /Spot2 /Spot3 /Spot4] >>
setpagedevice" -f -sOutputFile=c:\gauguin.psd c:\gauguin.ps

I am not sure how psdcmyk works, but I haven't noticed any calls of
gx_default_copy_color() through processing. I know little about printer
drivers (like psdcmyk) but I think they may by-pass the
gx_default_copy_color() function, at least for this type of ps files
(containing type 1 images with interpolate = true). My driver is not a
printer driver, so obviously here is the difference (and the difficulty in
reproducing the problematical behavior).

In case of you still aren't sure about the problem and about my proposed
patch, you may try non printer
devices able to work with 12 or 16 bits per component to reproduce the bug;
Russel's display device may be suitable for this.

Best regards,
Zoltán
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gauguin.zip
Type: application/x-zip-compressed
Size: 14351 bytes
Desc: not available
Url : /pipermail/bug-gs/attachments/20031115/343529f7/gauguin.bin