Simulating with a dLink in iQueue
Simulating with a dLink in iQueue
- Subject: Simulating with a dLink in iQueue
- From: Henrik Holmegaard <email@hidden>
- Date: Wed, 10 Mar 2004 14:03:38 +0100
"Treetop Publishing, Inc." <email@hidden> writes:
>File gets converted into the colorspace for the 9600 before printing.
Same
>converted file runs thru IQueue with the device link profile and then
gets
>printed on the Xerox 7700. What of the rendering intents?
>
>Is this most ideal? Should I be using the 'simulated printer'
instead?. In
>the end, the file for the 9600 will be ripped into a tiff and then
>repurposed for the Xerox to show what the 9600 print will look like
before
>it is actually imaged.
Cedric,
When you opt to match with a device link, embedded device profiles and
rendering intents in the embedded device profiles don't apply. Assigned
device profiles and rendering intents don't apply either.
(In the following the term Color Model, used in the iQueue UI, was
chosen because Chris Cox preferred to distinguish Color Model for the
generic data type from Color Space for the location of a gamut defined
in CIE co-ordinates.)
Now, if you open the iQueue user guide on the pages that describe how
to work with dLinks, you will notice that the guide explains that when
a device link is set for a color model and data type, the corresponding
device profile options are disabled.
For instance, in the Device Link dialog load a dLink for the CMYK color
model and the data types raster and vector. Now switch to the Source
and Destination dialogs where you will see that the corresponding
dialogs are disabled.
The ICC Specification calls a device link a "pre-evaluated transform".
On page 28 the iQueue guide explains that a device link is built by
taking a single rendering intent table from each profile in the source
- (simulation if you have one) - destination chain.
At its simplest the term "pre-evaluated" means that for Source Space_1
you cannot cycle through Destination Space_2, Destination Space_3 . . .
Destination Space_n, because the source and destination are locked to
one another.
In other words a fixed device link conversion is mutex with a modular
conversion with device profiles which link on the fly across the
connection space. It is important to see this because the implication
is that a device link workflow ignores device profiles.
In order to use a device link to advantage, you should make sure that
all objects you place in the InDesign or QuarkXPress page are
harmonized. For instance, all CMYK objects must be converted into a
_single_ CMYK Working Space.
The iQueue guide gives the general principle for object level color
management in page design workflows that you should harmonize with a
hotfolder workflow before placing objects in the page.
Page 28 of the iQueue describes what you are doing with a device link
as assigning an assumed source profile, because though the objects in
your page are correctly tagged with ICC device profiles, as per the ICC
Specification device profiles are ignored.
If you match a PDF with dLinks, you cannot embed the link as source
profile in the matched file, because embedding dLinks is illegal as per
the ICC Specification.
I'm not sure if the Color Police will come get anyone who might manage
to wiggle a dLink into a place where it does not belong, but that is
another matter -:).
Thanks,
Henrik
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.