Re: The MESS at the PRESS campaign
Re: The MESS at the PRESS campaign
- Subject: Re: The MESS at the PRESS campaign
- From: Henrik Holmegaard <email@hidden>
- Date: Sun, 11 Apr 2004 10:08:30 +0200
On Apr 5, 2004, at 4:19 PM, Henrik Holmegaard wrote:
The device link assigns an assumed source and then converts into the
proof space. How does the person preparing the proof know that the
assumed source represents the objects in the page when that person did
not harmonize the objects in the page in the first place ?
On onsdag, apr 7, 2004, at 00:10 Chris Murphy wrote:
They don't,
Thanks, that is what I intended to have MacWorld concede. I take it you
are conceding the point on behalf of MacWorld. I don't mind loosing an
argument to MarWorld, but I mind having to apologize to a customer for
less than perfect documentation.
Furthermore, I appreciate the support as there are many sources of
misinformation about device links, some due to poor understanding among
ourselves and some due to deliberate misleading among the proprietary
people.
In the first category I would place the MacWorld positioning of device
links which does not address the consequences of implementing them
before PostScript is streamed or PDF is exported, and after said both
are completed.
In the first category I would also place the Virtual CMYK argument by
Dave McDowell which was launched in the late 1990s, and which the
iQueue documentation had in mind for its description of a correct
workflow for device links.
In the first category I would finally place a number of developer teams
who have speculated in and in some cases have gone to prerelease before
discovering to their dismay the consequences of implementing support
for ICC device links.
In the second category I would place the proprietary people who
disregard the necessity to harmonize the objects in the page for the
intended printing condition and encourage the use of non-ICC device
links with
(1) no conversion for the print and conversion for the proof, or
(2) blind double conversion (*) for the print and conversion for the
proof.
(* If an ICC or proprietary device link is used to harmonize objects
for the print before the page assembly, or if objects are placed in the
page in any mix of CMYK and a device link is used to harmonize objects
for the print after PostScript is streamed or PDF is exported, then
given that an ICC device link or proprietary device link is mutex with
all ICC device profiles (: plus with CIEL*a*b*) having the same data
space as the first data space in the device link, and will disregard
the _given name_ of the device profile in relation to the _given name_
recorded or not recorded in the Profile Sequence (PSeq) tag of the ICC
device link, then it follows that both correct and incorrect CMYK will
be reseparated for the print which entails (a) double conversions and
(b) no solution to the gotcha that some CMYK objects in the page will
have too low ink limits / too low gamut to begin with. As in the
cookbooks the rule is that one cannot get on the destination side what
one cannot define on the source side which is one reason a CMYK
workflow is a loosing game from the start. And that must be the world's
longest and most convoluted sentence ever -:).)
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.