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: Chris Murphy <email@hidden>
- Date: Sun, 6 Jun 2004 20:07:57 -0600
On Jun 6, 2004, at 6:33 PM, Roger Breton wrote:
Absolutely. Tagging is the way to go ... if and only one operates from
a
well-behaved high-end pro dtp app like InDesign.
InDesign is fairly sophisticated, but its color management
implementation is wholly inadequate while being simultaneously complex
considering how vast the application is. 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.
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.
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. 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.
ICC profiles do not exist in a PostScript stream.
Of course they don't. But they do in PDF.
You set the context to Distiller which implies a PostScript source file.
Fair. And you know that there are still many outfit that refuses PDFs
prepared by anything but Distiller.
What's the reasoning?
That's my point. Distiller should not
deny the user of a CMYK workflow.
Feature request. But I think given that it would rely on the perversion
known as PostScript Color Management, I think that's reason enough
alone to not support it. Besides the feature would only work with
applications a.) capable of converting embedded ICC profiles into CSAs
and b.) actually configured to convert embedded ICC profiles into CSAs.
Otherwise you'd get a bogus profile assumed as source, ignoring actual
embedded source profiles in placed document objects, and that is worse
than not having the option to begin with.
And selecting PDF/X-1a under the PDF/X tab
does nothing to help the situation, it will attempt distilling the
PostScript and merely report compliance failure if it finds any object
not
in CMYK? That's a half-baked solution. Totallly useless -- no less.
The burden is placed on preparing the document correctly from the get
go. Distiller is not a preflight or PDF repair tool.
Provided the receiver has any kind of color managed workflow setup
properly.
AND that they think of changing their color management setup according
to
the OutputIntent. That's pretty dicey proposition. Hope that by
Acrobat 7,
PDF/X-1a will automatically be displayed on screen and inkjet proofed
according to the OutputIntent in the file.
By default it does this now. It's not automatically set in Proof Setup,
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.
But it is used as the source profile for both on-screen display and
when printing.
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). 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.
If you send the job to the proofer configured to simulate actual
press conditions defined in the print job, it will still proof
correctly. The OutputIntent is an implied but non-binding source
profile.
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.
It's metadata.
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? I suppose that might get things fixed a whole lot
quicker...
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.