• 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: Remote proofing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remote proofing


  • Subject: Re: Remote proofing
  • From: Henrik Holmegaard <email@hidden>
  • Date: Sat, 13 Mar 2004 18:30:01 +0100

On lxrdag, mar 13, 2004, at 04:53 Europe/Copenhagen, Roger Breton wrote:

What you ask is nothing less than the ability to convert any placed images
in InDesign to any output profiles! A many to many relation, in database
parlance. < . . . > One output profile per document is plenty.

Right, so let's drive a six inch spike through this concept to make sure it _really_ punctures -:).

As previously noted I doublechecked the concept of object level color management for the Adobe side before starting this tread. And after LogoProof, BatchMatcherPS and iQueue I don't think I have to check the concept of object level color management on the GretagMacbeth side.

For a number of years I have seen the persistent call from U.S. consultants for multiple destination spaces. The U.S. claim is that this is a requirement for high quality object level color management. The question then is if this _is_ a requirement for high quality object level color management, or it is another U.S. misunderstanding.

In the PostScript Level 2 release 1 approach there is a support for objects which are device color and objects which are CIEBased color, that is, objects which reference a Color Space Array. Device colors are rendered by the numbers and CIEBased colors are matched to the resident CRD.

As designed there is only a concept of _one_ CRD because there is only _one_ definition of the media state which the interpreter is targetting.

I asked Adobe cc the ECI if it might make sense to write into the EPS Specification that embedding of CRDs is disallowed / illegal.

In principle it is possible for a PostScript programmer to embed a CRD in an EPS and for say QuarkXPress to emit passthrough PostScript with multiple CRDs in the page.

After chewing on the issue a bit the answer was that the text of the EPS Specification will not be extended (1) because nobody has yet been crazy enough to embed a CRD in an EPS and (2) short of manually encapsulating PS coming out of InDesign there is no way an Adobe application might be involved in embedding a CRD in an EPS.

Though the TechNote that introduces the OutputIntent changes the position for PDF from using only the ToCIE direction in embedded ICC profiles to using the full ToCIE and FromCIE model, there is still only _one_ OutputIntent profile allowed.

Similarly, if iQueue embedded multiple (bidirectional) destination profiles in a matched PDF this would be considered a bug and most certainly not a feature.

When Chris has called for multiple destination spaces it has been in the context of a bug with black replacement in ICC device profiles.

If for the same characterization table and the same ink limit setting the print profiling software does not deliver the same color for multiple black replacement settings, then this is technically a bug in the print profiling software.

But from the fact that print profiling software may have a bug it does _not_ follow that either the PostScript CMS or the ICC CMS should implement a concept of multiple destination spaces for the same printing condition.

EPS is a _lousy_ format because it mimics the quality criteria of the repro camera operator. It is possible to embed a per image transfer function in PostScript Level 1 release 1 because on the repro camera it was possible to do a per image tonal adjustment. It is possible to embed per object screeing because on the repro camera it was possible to render screening on a per object basis. And the separation with manual filters was likewise controlled on a per object basis in the repro camera as it is in deviceColor EPS and EPS DCS. This is the pits on the press, with every object rendering different from every other object and no way to calibrate the ink zones.

In PDF/X-3 embedding of transfer functions and all this other non-sense is called out and you get shoved into the slammer for doing it. Come on folks, get real, there is no law that prohibits commonsense thinking (even if it seems there might be at times -:)).

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.


  • Follow-Ups:
    • Re: Remote proofing
      • From: Roger Breton <email@hidden>
  • Prev by Date: Re: LinoColor 16 bit output? - Thank you!!!!
  • Next by Date: Re: Remote proofing
  • Previous by thread: Re : Remote proofing
  • Next by thread: Re: Remote proofing
  • Index(es):
    • Date
    • Thread