'In the RIP' ABC
'In the RIP' ABC
- Subject: 'In the RIP' ABC
- From: Henrik Holmegaard <email@hidden>
- Date: Wed, 30 Jan 2002 11:14:14 +0100
Chris Murphy <email@hidden> wrote:
The above method I'm describing is better because neither InDesign nor
QuarkXPress can produce complete proofs of all content unless you go with
only TIFFs and PICT (and maybe JPEG). EPS's do not get color managed. So
if you want everything processed, you would need something that can parse
PostScript - either a color server in between the workstation and the
RIP, or do it in the RIP.
It's important to specify which color management framework operates
where in the workflow.
'In the RIP' in the above context does not mean 'using a PostScript
color management framework'.
'In the RIP' here means 'using the ICC color management framework'.
It is confusing that from the point of view of PostScript color
management (i.e. the CMS built into PostScript Level 2 and PostScript
3), anything to do with ICC color space specifications is not
managed. From the perspective of the PostScript RIP, (a) you can
build an ICC front-end into the RIP itself, (b) you can run
PostScript through a color server placed between the application that
writes PostScript and the RIP, (c) you can manage color in the
application that writes PostScript using an ICC framework, or (d) you
can manage color before the application that writes PostScript (:
using iQueue hotfolders), but by definition all four options are
'host-based color management'. Actually, the PostScript color
management framework doesn't care whether the four steps above use
the ICC framework wholly, mix in proprietary scanner firmware
conversions, or use only proprietary conversions. It's all
'host-based' just the same.
The problem with EPS (and PDF) comes from historical disagreements.
The original idea was that the content creator was responsible for
the content. The scanner operator would use her proprietary firmware
RGB to CMYK device links to get the best separation which was then
encapsulated into a locked format which the assembly application (aka
QuarkXPress or PaceMaker) would leave untouched. The illustrator
would use another equally locked color management model: The printed
CMYK or Pantone swatchbook. Adobe Illustrator had no concept at all
of device independt hand-off until version 9!
The problem is the user culture, the culture of contracting for
color. Type designer Matthew Carter taught me that one cannot design
for a technology that has one intimidated. As long as content
creators are intimidated by the workflow (as well they may be), then
they will be tempted to ask for locked formats and to require that
the locked data remain firmly locked in perpetuity.
At the end of the day the technology is no better than the people it
is built for. If we don't ask for better technology, we won't get
better technology.
You can manage color in an increasing number of post-application ICC
implementations, iQueue (BatchMatcherPS...), BESTColor and now also
the HP 10ps / 20ps with a software RIP that runs on the Mac and
supports cross-rendering. This RIP supports calibration, too. It even
comes with the printer itself.