Re: Further on CMYK -> Lab
Re: Further on CMYK -> Lab
- Subject: Re: Further on CMYK -> Lab
- From: Henrik Holmegaard <email@hidden>
- Date: Sat, 24 Mar 2001 07:41:49 +0100
Jan-Peter wrote:
The problems seems to me, that the Checkbox "PostScript
Colormanagement" in the
"Save EPS" Dialogue from Photoshop causes such problems.
Politely censuring the string added to the title (... -:)) it is true
that if Photoshop 5 and 6 didn't offer the user -
a. embedding of a CMYK CSA,
b. double-embedding of a CMYK CSA and an ICC profile,
Distiller and InDesign would act consistently with their UIs. Also
this double embedding of two different source profile formats, one
that only works outside the RIP and one that only works inside the
RIP, is a recipe for disaster.
I would be very glad, if there would be a possibility to hide this checkbox
from the user in "Save" dialogues, and if the hidden checkbox would be the
preference in every Adobe programm after first time installing.
I'll second that.
The second whish is a program, which hides the "PostScript Colormanagement" in
every printer dialogue.
How about changing that to proper documentation that states the problem?
QuickDraw and GDI are RGB-only so there is no way for applications
that don't write PostScript to tell a CMYK printing device what to
do. The only way is for the user to choose either ColorSync Color
Matching or PostScript Color Matching in the OS print dialog.
The painful problem for Apple is that to help users out, the company
has to say that desktop publishing isn't a question of which OS you
are working on, but of which applications you are working in. It is
not the OS but the application that generates PostScript in which you
have support for CMYK (RGB, CMY, K, Lab etc.).
If the industry had accepted QuickDraw GX we would have had an OS
with CMYK support, device independence too, smart fonts ...
document-centric workflows ... the lot.
Quark and Adobe didn't want QuickDraw GX and document-centric
computing. The former because QuickDraw GX and smart fonts were a
rival to PostScript. The latter because it broke with the business
model according to which Quark and Adobe enhance their software
through incompatible APIs and armies of extensions and plug-in
developers - in Apple's model we would have had compatible applets
and an army of small new developer companies with exciting new
products that competed with Quark and Adobe suites.
It remains to be seen whether the acquisition of a CMYK imaging model
in OS X finally gets us out of this mess where applications bypass
the OS printing pipeline because the OS printing pipeline is forced
to be RGB-only.
I can't imagine any workflow, where PostScript Colormanagement is some kind of
advantage.
As a default color server :
The fact that PostScript supports both CMYK, CMY, K, Lab and RGB all
in the same file, and the fact that PostScript and subsets of
PostScript (EPS and PDF) act as embedded objects whose content isn't
read by the application in which these objects are placed, also means
that a good RIP must have a way to handle
a. color models it doesn't support (for a CMYK RIP meaning RGB and Lab)
b. color models it supports with objects whose channel values are way
way out for the media state the RIP is imaging for.
Most applications write deviceCMYK, so if you create a set of high
TAC and long black images in Linocolor, and print them from Quark to
an inkjet proofer RIP as you would print to an imagesetter to make a
Cromalin (no CMYK to CMYK conversion), then the TAC and black
generation will be altogether wrong for the inkjet, and the
reproduction quality will be poor.
In this case, if you don't have iQueue or BESTColor or PosterShop or
some other ICC color server in front of the inkjet RIP, then the RIP
itself must have a simple color server implemented that assigns
assumed source CMYK CSAs and assumed source RGB CSAs to incoming
data. This is what the HP folks in Barcelona were pointing out last
year when the List discussed host-based versus in-RIP at length.
The argument for using in-RIP as a default color server is a good
one, given the limitations of the Mac / Windows OS and the lack of
CMYK to CMYK color management for the print path.
--
------------------------------------------
Henrik Holmegaard, TechWrite
Stationay +45 3880 0721 - +45 3881 0721
Mobile +45 2178 3959
Toelloesevej 69, 2700 Broenshoej, Denmark
------------------------------------------