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: Mon, 5 Apr 2004 23:56:54 +0200
bruce fraser <email@hidden> writes :
>When "the industry" does in fact standardize on no more than ten
printing
>conditions, we can revisit this discussion, but today's reality is
that printing
>conditions are becoming more, rather than less diverse
The answer to Darrian came in sections. The sections are numbered at
the bottom. The passage you discuss reports what the Virtual CMYK
workflow was intended to be.
The passages that follow discuss why reseparation with device links
before the Virtual CMYK separations were placed, or reseparation with
device links after the PostScript stream is emitted, would be a blind
conversion which failed to distinguish between the Virtual CMYK
separations which were correct for the intended printing condition and
the Virtual CMYK separations which were incorrect for the intended
printing condition.
Again, a device link is device dependent on the data in and device
dependent on the data out side, as miscellaneous documentation explains
in order to make it clear why the user should harmonize / normalize the
CMYK before assigning a device link.
>Factor in the tendency of US printers to treat standards as something
to
>be exceeded rather than met, and you'll find that the concept is miles
away
>from any foreseeable reality.
I would say that the paper in which Virtual CMYK was originally
published was intended to give prepress and print a manageable number
of generalized "CMYK working spaces" and a one-size-fits-all conversion
technology to make sure that reseparation at the press produced the
desired ink limit and black replacement.
I would also say that the paper assumed the use of modular device
profiles up until the separation for the intended printing condition,
but as in actual LinoColor / EskoColor / XYZColor workflows the CMYK
was handed off untagged. The paper was written in the late 1990s when
page design was not ICC-enabled.
>In the case of a dLink, all that is needed for proofing is to assign
the destination
>end of the dLink to the converted source material.
Of course, that's what I wrote.
>Factor in the tendency of US printers to treat standards as something
to be
>exceeded rather than met
The same line can be searched in the Archive from, I think, late 2000
or early 2001.
>You are making this much more complicated than it really is.
How does advocating the simple rule that we harmonize the separations
for the print either before the page design or in the page design make
things more complicated?
How does advocating laying down any mix of CMYK without converting for
the print and then handily converting for the proof make things less
complicated?
How does advocating the use of ICC device links, if need be, over
proprietary device links we cannot inspect make things more complicated?
Can we stay on topic for a short stretch. Spend a couple of hours and
start from the beginning to explain how you would write documentation
for the recommended deployment of ICC device links in a page design
workflow.
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.