• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: The MESS at the PRESS campaign
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Prev by Date: RE: The MESS at the PRESS campaign
  • Next by Date: RE: The MESS at the PRESS campaign
  • Previous by thread: RE: The MESS at the PRESS campaign
  • Next by thread: RE: The MESS at the PRESS campaign
  • Index(es):
    • Date
    • Thread