• 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: Re(6): embedded profiles in PDF/Postscript
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re(6): embedded profiles in PDF/Postscript


  • Subject: Re: Re(6): embedded profiles in PDF/Postscript
  • From: Chris Murphy <email@hidden>
  • Date: Sun, 6 Jun 2004 20:51:58 -0600

On Jun 6, 2004, at 8:23 PM, Roger Breton wrote:

It has essentially the same
functionality as Photoshop, just on an object by object basis and even
that is limited. It's very easy to screw up color managed jobs in
InDesign CS, and in InDesign 2 it's not usable unless you're willing
to a.) not print to a printing press or b.) never embed profiles in
CMYK images.

I see. That has not happened to me yet. I'll keep an eye open.

In InDesign 2 if you embed profiles in CMYK images, and they are not identical to Document CMYK, each of those objects will get converted at print time. It doesn't matter what the color management policies are set to, they get converted. Your option is to selectively, one by one, turn off color management for each of these objects while preserving the embedded profile. Fortunately CS rescues this problem but while it still tracks the embedded profile it ignores it by default and makes it a very manual process on a per object basis, to reinstitute the embedded profile if you decide later you want to repurpose the document. Basically repurposing CMYK in InDesign is so irritating that you'd need a very high pain tolerance to attempt it which is why most people don't.


What I'm describing is out of Office X and Acrobat Pro v6.

Ahh yeah I see that now. If you export PDF directly, everything is ICCBased, tagged with Generic RGB. If it was a TIFF and had an embedded profile, it gets converted from that space to Generic RGB and tagged Generic RGB.

But if you print PostScript, you get CalRGB. One of the constistent problems I've had with Distiller is that supposedly if it encounters a CSA derived from an ICC profile that is on the local machine, it will substitute and embed the original ICC profile instead of converting the CSA into an unnamed ICC profile (which might be what's going on with everything being CalRGB when you print PostScript & distill). But to date I've never seen this feature work but a handful of times. Usually the original profile name is stripped and I have no idea what the source really is or if it's right. Another reason why I'm severely biased against PostScript color management.


But whatever gets embedded should be the assumed
source, superceded by any profiles embedded in placed objects. CalRGB
can contain primaries and tone response information, but not other
information about the source profile such as the name. Better than
nothing, but not ideal.

I find it has some merits, on the face of it, being a monitor space.

It's not any one thing apparently. It's basically a set of defined primaries and maybe a tone response curve.

But it is used as the source profile for both on-screen display and
when printing.

Are you sure? How can I test this, simply?

Use InDesign to set a really horrible OutputIntent, an export PDF/X-1a. I find it easier to test using PDF/X-3 because then I can have an RGB OutputIntent, and select an Epson 2200 canvas profile. Really bad. If it's being used, you'll know it.

Then in Acrobat alternately check and uncheck the Ignore OutputIntent option in color management preferences.


Because it's better for the metadata to be there than for it to not be
there. It's better to have standards than to not have standards. There
will always be improper application of metadata and standards (Apple's
claim of supporting PDF/X-3 in Panther while not at all producing valid
PDF/X-3 is one such example), that by itself does not mean the standard
is useless. Diluted perhaps, but what do you propose, taking off a leg
for every offender?

No but throw them out the front door by the seat of their pants.

That's not easy to do, especially with professional software that gets it wrong. That Panther doesn't make PDF/X-3 and always sets the OutputIntent to TR001 even if you select some other destination space (i.e. bogus OutputIntent that does not describe the meaning of the numbers in the file; how much worse does it get?) is minor because almost no one will find it in the bowels of the ColorSync Utility, let alone use it. But in a professional application people are very likely to use these things and get into a heap of trouble very quickly, and then where are we? Stuck using a piece of software with a major color management disfunctionality in it for its entire product life cycle.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management"
Published by PeachPit Press (ISBN 0-201-77340-6)
_______________________________________________
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: Re(6): embedded profiles in PDF/Postscript
      • From: Roger Breton <email@hidden>
    • Re: embedded profiles in PDF/Postscript
      • From: Graeme Gill <email@hidden>
References: 
 >Re: Re(6): embedded profiles in PDF/Postscript (From: Roger Breton <email@hidden>)

  • Prev by Date: Re: Re(6): embedded profiles in PDF/Postscript
  • Next by Date: Re: embedded profiles in PDF/Postscript
  • Previous by thread: Re: Re(6): embedded profiles in PDF/Postscript
  • Next by thread: Re: embedded profiles in PDF/Postscript
  • Index(es):
    • Date
    • Thread