Re: Update on HP 10/20PS printers
Re: Update on HP 10/20PS printers
- Subject: Re: Update on HP 10/20PS printers
- From: Johan Lammens <email@hidden>
- Date: Wed, 12 Dec 2001 18:47:05 +0100
- Organization: Hewlett-Packard
email@hidden wrote:
>
Fair enough, a simple single intent RGB backdoor is useful... rather than
>
having to convert all the images and color definitions to the inkjet profile.
It's not a single intent RGB backdoor: the rip will recognize and honor any
profiles (CSAs) and rendering intent selections in the PS file, which could be
global or per-object - but that obviously depends on the application generating
the file. Only for files that do not have embedded profiles (CSAs) nor rendering
intents will the selected input profiles (RGB and CMYK) and output rendering
intents be used, as well as the selected output profile obviously.
>
This approaches full flexibility (though this is the expensive model, a
>
comparison to a cheaper RIP and a color server is still in order) but I would
>
need to see it work with, say, a six channel press profile before I got too
>
excited... if that is possible you have my undivided attention! Can that
>
"press CMYK" be "press CMYKOG" if the profile is available?
The color proofing functionality of the 50ps rip is quite complex, and not easy
to explain in a couple of sentences - but here is my attempt at summarizing the
answer to your question:
- Jobs that contain both objects (images and vectors) in CMYK and objects in
spot colors are proofed correctly. Spot colors are handled via internal lookup
tables (if "Automatic Pantone Calibration" is enabled) that translate spot color
names into device/ink/media/printmode dependent CMYK[cm] values, or their CMYK
equivalents are taken from the PostScript job as a fall-back if no table lists
the color's name and replacement CMYK values. This part is true also for the
10/20ps rip.
- The 50ps rip has an "Emulation of spot color printing" checkbox in the WebUI.
If that's off, the rip will take all objects in the job and render them one by
one into the four [six] output planes, from background to foreground. An object
in a Pantone color would knock out what was behind it in the C, M, Y, K planes.
Pantone objects would be treated just as any other CMYK object, except that no
further color matching is applied. If the checkbox is on, the rip first makes a
list of all spot colors found in the job, looks which of these it can find in
the internal spot color tables, and then uses the standard four CMYK planes plus
one for each of the spot colors that were found. All the extra planes are merged
into the CMYK planes post-rip with a simulation of the press output. The CMYK
planes remain untouched where all spot color planes are 0%. And where only one
spot color is printing, that color would be proofed accurately, of course always
within the device's gamut limits. Overprinted spot colors are rendered with a
custom algorithm which results in a pretty good press match (overprints are not
listed in the tables, of course). Calculating overprinted spot colors is
difficult, to say the least.
- Regarding proofing with non-CMYK profiles then. There is no way to pass
Hexachrome data as 6 channel data into the 50ps rip directly. However, depending
on how the applications generate Hexachrome separations, working with these
files is possible if the channels are defined as CMYK + 2 spot colors (Orange
and Green), or as 6 spot colors (C,M,Y,K,O,G). They would be treated as
mentioned above. It is not possible to use N-channel ICC profiles in the rip to
do color separations and proofing. DCS-files are not supported directly, but
inserting the DCS-file in a Quark (or InDesign) job and creating a separated PS
file you can "proof" this on the 50ps as long as the used colors (the name of
the colors and their device color equivalents) are defined in any of the
internal color tables. "Proof" means that it is not a real colormanaged proof,
but rather a simulation of spotcolor output using the overprint algorithm
mentioned earlier. The results are quite good, but you'd have to judge for
yourself.
Johan