Bug 687903 - CMYK printer prints CMYK mixture instead of black
Summary: CMYK printer prints CMYK mixture instead of black
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: 8.16
Hardware: All All
: P4 major
Assignee: Michael Vrhel
URL: http://home.t-online.de/home/Martin.L...
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-20 15:38 UTC by Till Kamppeter
Modified: 2010-12-02 18:01 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
This patch fixes this bug. (416 bytes, patch)
2005-01-20 15:39 UTC, Till Kamppeter
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2005-01-20 15:38:04 UTC
Report with fix cited from Martin Lottermoser's pcl3*/doc/ds-mods.txt in the
"pcl3" driver package available on the site mentioned in the URL in this report:

------------------------------------------------------------------------------
 C1 There is a bug in ghostscript's default configuration for the
    undercolour removal and black generation functions. It shows up when
    printing PostScript documents using the RGB colour space ("setrgbcolor" or
    "sethsbcolor") on a device where the CMYK space is the native colour space;
    this is the case for pcl3 if you specify "-sColourModel=CMYK". The bug
    results in black being printed as a mixture of cyan, magenta, and yellow.
    On my printer, this is a slightly greenish grey with fuzzy edges.

    To check for the presence of this bug, run gs on the following command:

      0 0 0 setrgbcolor [ currentcmykcolor ] ==

    gs will issue "[1.0 1.0 1.0 0.0]" on standard output if it would print the
    mixture and "[0.0 0.0 0.0 1.0]" if it would print true black. You should
    specify a CMYK device like "bitcmyk" for this test.

    To correct this behaviour, you'll have to modify gs_init.ps. Look for the
    following lines (starting at line 1263 in AFPL gs 7.0 and at line 1247 in
    GNU ghostscript 6.51):

      % Set the default screen and BG/UCR.
      /.setdefaultbgucr {
	systemdict /setblackgeneration known {
	  { pop 0 } dup setblackgeneration setundercolorremoval
	} if
      } bind def

    Replace the line containing "setundercolorremoval" with the following:

      {} dup setblackgeneration setundercolorremoval

    I had reported this bug to L. Peter Deutsch on 1998-12-09 and he wrote he
    would change the behaviour in the next release. This happened subsequently
    in gs 6.0 (released 2000-02-03), but gs 6.01 reverted to the previous
    behaviour.

------------------------------------------------------------------------------
Comment 1 Till Kamppeter 2005-01-20 15:39:22 UTC
Created attachment 1170 [details]
This patch fixes this bug.

I have tested and the attached patch fixes the bug in the cited report.
Comment 2 Raph Levien 2005-01-26 09:34:03 UTC
I'm wary of changing the default behavior here. Peter's note from the 1.3 commit
to gs_init.ps reads:

Changes the default undercolor removal and black generation functions back
from f(k) = k to f(k) = 0.  This fixes some, but not all, of the reported
problems with color inkjet output in 6.0.

This suggests that applying the patch will break almost as many currently
working devices as it will fix new ones. I think that the upp drivers, in
particular, expect the 6.01 behavior.

Also, the choice of default undercolor removal is not really a "bug". The PS
reference states fairly clearly that the undercolor behavior is dependent on the
device.

I definitely understand that the 6.0 behavior is better for your printer. I
would accept a patch that makes it easy to get the 6.0 behavior but does not
change the default. I would also accept a patch that changed the default
behavior as long as I have some assurance that all existing devices which expect
the 6.01 behavior are patched to work with the 6.0 undercolor. That's a big
testing task, but maybe Till is up to helping with it.
Comment 3 Till Kamppeter 2005-01-28 09:41:19 UTC
Perhaps an option should be added to switch between the different behaviours,
but I cannot supply a patch for it. I am not so deep into the internal
structures of GhostScript to quickly introduce such an option.

I also cannot test all drivers concerning this change as I have to see the
printouts for that and I do not have all printers.
Comment 4 Ralph Giles 2008-05-20 17:18:59 UTC
Passing to Michael for a decision and/or implementation.
Comment 5 Michael Vrhel 2010-12-02 18:01:10 UTC
These issues are now handled by setting the proper ICC profiles.  Closing this bug.