Re: Re(6): embedded profiles in PDF/Postscript
Re: Re(6): embedded profiles in PDF/Postscript
- Subject: Re: Re(6): embedded profiles in PDF/Postscript
- From: Roger Breton <email@hidden>
- Date: Sun, 06 Jun 2004 22:23:44 -0400
>
InDesign is fairly sophisticated, but its color management
>
implementation is wholly inadequate while being simultaneously complex
>
considering how vast the application is.
It is huge. And I don't like the fact that it does not make its conversions
explicit to the user. For while, I even thought that PostScript Color
Management was the same as "Same as Source". Admittedly, out of ignorance on
my part but also out of a lack of documentation on screen. You and I have
discussed the shortcomings of the UI as far as coolor management in InDesign
is concerned many times.
>
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.
>
Good color management should be completely transparent and seamless to
>
the user. Better color management comes with the end user having a
>
better understanding of color management, their workflow and giving
>
that feedback to the application which in turn produces an even better
>
result. Right now that is definitely not the case. We either have
>
tricycle mode or space shuttle mode, and neither are particularly
>
transparent or seamless, and neither really gets us the result we want
>
without having to adjust our workflow to accommodate the application.
I like your analogies ;-)
>
> And I hear that there are
>
> still a fair volume of PDF being cranked out of Word or Excel or
>
> wherever
>
> and these use CalRGB or CalGray as color spaces.
>
>
That's the first I've heard of it. I don't have new copies of Office
>
2004 for the Macintosh yet, so I'm not sure how they behave in regards
>
to color management.
What I'm describing is out of Office X and Acrobat Pro v6.
>
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.
>
> Fair. And you know that there are still many outfit that refuses PDFs
>
> prepared by anything but Distiller.
>
>
What's the reasoning?
Politics, experience, ignorance. I've had my share of Exported PDFs out of
InDesign refusing to print. It's the exception rather than the norm, mind
you.
>
The burden is placed on preparing the document correctly from the get
>
go. Distiller is not a preflight or PDF repair tool.
Distiller lacks flexibility. Adobe is not in the business of dictating
workflows. Or is it?
>
By default it does this now. It's not automatically set in Proof Setup,
Right, it ain't automatic which it should.
>
nor can you even find it in Proof Setup, so technically you can't soft
>
or hard proof with either Simulate Paper White or Ink Black correctly.
OK.
>
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?
>
The one setting that can cause the OutputIntent to be ignored is the
>
Ignore Output Intent checkbox in Acrobat which I think is one of the
>
stupidest things the Acrobat team has done in a while (in a long list
>
of stupid things).
Oh!
>
The OutputIntent is sacrosanct compared to any other
>
kind of embedded profile and NO other profiles embedded in PDF can be
>
ignored by Acrobat except for this one! It's absurd they provided
>
users, yet again, with a major hurt me button.
Hmmm...
>
> Which reduces considerably its scope.
>
>
No it doesn't. It actually makes it a very safe, and very valuable kind
>
of profile. We have entirely too many applications very eager to
>
repurpose CMYK data that's tagged, and that's been a huge part of the
>
problem with getting people to embed profiles in CMYK images.
I see your point.
>
> It ends up being treated that way. So why bother in the first place?
>
>
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.
>
I suppose that might get things fixed a whole lot
>
quicker...
>
>
Chris Murphy
Roger Breton | Laval, Canada | email@hidden
http://pages.infinit.net/graxx
_______________________________________________
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.