Re: Why don't drivers use a CMYK profile?
Re: Why don't drivers use a CMYK profile?
- Subject: Re: Why don't drivers use a CMYK profile?
- From: Henrik Holmegaard <email@hidden>
- Date: Thu, 9 Nov 2000 13:54:51 +0100
Dave Camp <email@hidden> wrote:
So, why don't drivers use a CMYK profile to convert directly from source RGB
to printer CMYK values, instead of converting from source RGB to printer RGB
to printer CMYK?
Actually, I guess what I'm really wanting to know is: Is there a good reason
not to do that?
Recap: The QuickDraw printing pipeline is designed for
autoconfiguration. The printer vendor configures the internal RGB to
CMYK or CcMmYK conversion for his inks, papers, and print modes. This
pipeline is intended for applications that don't have a CMYK imaging
model, and don't have the ability to translate their internal data
structures into PostScript.
Issue: When you ask for a profile to be built, you are also asking
users to take control of TAC and black generation. For instance, how
will you as a user preset the device (ink, paper, print mode) so that
the testchart shows differentiation in all areas of the color space?
As a user you have to find a way to control the device, and keep it
in that state after the profile has been built.
The HP DesignJets have a mode that applies an ink cut-off, but
otherwise leaves the gamut raw. Because the TAC setup parameter is
built into the printer as a 'user friendly raw state', you can
profile the device without the extra hassle. But then we're already
talking about a complex printing system.
IOW it isn't just a question of being able to add a CMYK profile for
the actual device color state (actual paper, actual ink, actual
machine make and model serial no., etc.), but also of an extra system
that has to come with the printer for end-user profiling to make
sense.
(BTW I've some mail trouble, sorry if this post is already redundant.)
--
Henrik Holmegaard
TechWrite, Denmark