Re: Update on HP 10/20PS printers
Re: Update on HP 10/20PS printers
- Subject: Re: Update on HP 10/20PS printers
- From: Henrik Holmegaard <email@hidden>
- Date: Fri, 30 Nov 2001 21:09:42 +0100
David wrote:
It has an internal sensor for... as many HPs have in recent
years. That won't stop you from building custom device profiles for the
printer on top of that base liniarization. The real limitation is that it
won't support press emulation profiles, but instead requires the files to be
in press space to emulate a press.
For 'liniarization' read 'linearization', no ? ... -:)
And of course you can build custom device profiles on top of the
linearization, just as you can build custom device profiles on top of
Iris ColorZone linearizations or Kodak ColorFlow linearizations. No
linearization, no calibration, no cheque for the printer.
The second half of the paragraph is kind of odd, if you re-read it.
When you color manage in the application that writes PostScript, then
in theory you can have a source space and rendering intent for each
object, and manage all objects to the Separations output space as
well as to the Composite proof space. I think this is what you mean.
When you color manage PostScript, you assume that all objects have
been correctly harmonized to the Separations color space. Then your
job is to convert the colors (including the separation) from the
Separations color space to the Composite space using a colorimetric
conversion.
We all know this assumption is a fond thought. Page assembly
applications either are not ICC enabled or ICC functionality is
disabled by the user (because it's ridiculously slow cf QXP 4.X) or
pages contain placed objects in formats the application doesn't color
manage notably PDF and EPS (for QXP and InDesign both).
One option is to insert an ICC color server in the print path e.g.
iQueue. So when a PostScript job has both RGB and Lab and CMYK and
Greyscale color models and both vector and raster objects, you can
use the color model and data type to set up a filter that assign
assumed source profiles to objects in the file, even if you don't
know what the actual source was.
Another option is to convert the colors (including the separation) in
the RIP, assigning assumed source profiles to objects with unknown
source spaces in the same way. For assumed source spaces t he
DesignJet PostScript pipeline supports AdobeRGB(1998) and other
standard source RGB spaces, and CMYK offset spaces, too.
There are more filter functions in iQueue than in a RIP when it comes
to assigning source profiles and applying embedded profiles and
defining the individual steps in the profile chains, and iQueue can
be placed in front of the application that writes PostScript so that
all data formats you wind up placing in the page are correctly
harmonized to the Output/Simulation color space which you can't do
with a RIP-based color server, but no matter where color spaces are
harmonized the idea is to get the data objects into the Separations
space or you can't cross-render the Separations sapce into the
Composite proof space.
OK, back to speed typing this end, too -:)