[gs-bugs] [Bug 689961] Radial gradation issue

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Thu Jul 10 08:51:45 PDT 2008


http://bugs.ghostscript.com/show_bug.cgi?id=689961

marcos.woehrmann at artifex.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P4                          |P2



------- Additional Comments From marcos.woehrmann at artifex.com  2008-07-10 08:51 -------
Additional information from the customer (including a command line, which should satisfy Henry):

First, I've found the reason why I couldn't reproduce the problem with
tiff32nc: it's because the gradation, in the file, is in a DeviceN
colorspace, having only one component, "Magenta". And since tiff32nc
uses the default get_color_comp_index procedure
(gx_default_DevCMYK_get_color_comp_index), it identifies "Magenta" as
one of it's colorant, so it uses gx_concretize_DeviceN(), and then
finally cmap_devicen_direct(), to map all colors of the gradations.

In my first attempt, I had tried to redefine the mapping proc
CMYK->CMYK of tiff32nc, because I thought that the file was pure CMYK.
God knows why, when you have a gradation in Illlusrator CS3 with only
process CMYK colors, it always create the gradation in a DeviceN
colorspace, when the output is PDF.

Now, the reason our CMYK devices works differently than tiff32nc is
that our get_comp_color_index() always return -1 for process inks. And
the reason for that is, precisely, to force DeviceN colorspaces to be
processed like DeviceCMYK, so that our mapping procs (which make an
ICC conversion) are always used. Well, stricly speaking, the initial
motivation was to disable overprint on process colors (that was a
suggestion of Dan Coby a few years ago). I found out later that this
has this rather happy side effect, too.

Anyway, I finally could reproduce the initial problem with tiff32nc, by:
a) redefining get_color_comp_index() to always return -1.
b) redefining the cmyk mapping proc in such a way that it returns
exactly the same values than my own device (with a look-up table).

I attach the modified gdevtsep.c (my modifications are in #ifdef
DO_MY_CMYK), for version 8.62. To produce the buggy TIFF, use the
following command:

gs -sDEVICE=tiff32nc -sOutputFile=a.tif -r60 -f SimpleGradMag.pdf

(I attach again the problematic PDF file).

As far as I can see, the problem is in
gx_cspace_is_linear_in_triangle(). At first glance, it wrongly
decides, at a certain point, that no more subdivisions are needed
(besides, when I force gx_cspace_is_linear_default() to always return
0,  I  immediately  get rid of the problem). However, I'm not so sure
because if that was the case, I should normally end with a wrong
gradation (wrong colors), but at least a smooth one. So maybe there is
something else.

Now, the real reason of the problem might be that our device declares
itself as "separable and linear" whereas, in fact, it's not linear
(ICC conversions, especially with digital printers, are almost never
linear). But if that's the case then our device is buggy since the
beginning. And I think that when tiff32nc processes an RGB gradation,
it doesn't always make a strictly linear RGB->CMYK conversion. So
maybe this bug is potentially present with the standard GS devices.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the gs-bugs mailing list