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 17:08:32 -0600
On Jun 6, 2004, at 9:09 AM, Roger Breton wrote:
I see. You say that there is always the risk of either indicating the
wrong
pointer to a printing condition or embedding the wrong ICC profile. But
there is no way to protect against this kind of error, is there?
1. A calibrated display (ideally we'd all have only self-calibrating
displays)
2. An application that does display compensation; i.e. the profile to
be embedded is used as source for the data being displayed (and vice
versa), and the destination is the display profile.
3. The human recognizes that what they see on screen is a very close
representation of the colors they are asking for, when manipulating the
file.
If those three things occur, then the embedded profile is correct. Even
if SWOP is not the destination, if a user is working on a CMYK file,
tagged SWOP, and likes that image, the embedded profile is correct. If
the output conditions deviate substantially (admittedly there is a
moving threshold with that statement) from the source, then a
conversion is necessary. For soft proofing it's display compensation.
For hard proofing it's a full conversion. For printing to a press, it
rapidly gets dicey because there are all kinds of things we do and
don't want to have happen with such a transition from source to
destination, and the current implementations are severely lacking in
dealing with those problems.
Do these profiles exist anywhere in an 'ICC' format? Or will I have to
extract them out of an existing PDF file to open them up wih ColorSync
Utility? I'm curious to see what I will find out, because I've not
seen them
documented in the official Adobe PDF 1.5 Specifications anywhere. They
are
mentioned in the specs but not defined.
I'm not sure but they may not exist in PDF 1.5. They might be found in
PDF 1.2 and earlier, and carried over from those specs for legacy
support. I thought the terms were carryovers from the PostScript era
anyway. The method to use today is tagging with ICC profiles.
As you see, Adobe has not deemed important to offer a "Convert all
colors to
CMYK". Why? I would think that if I have a PostScript file with RGB
images,
each tagged with their own individual ICC profiles (some in AdobeRGB,
some
in sRGB and some with ColorMatchRGB), I would want to have a way to go
beyond merely tagging that data to actually converting those RGB
images to
whatheve CMYK Destination space and use that as my OutputIntent in a
PDF/X-1a. Or do you have that functionality in your Callas products
already?
ICC profiles do not exist in a PostScript stream. They get converted to
PostScript CSA's. So to do this, you'd be asking for a less than high
quality conversion asking the PostScript interpreter to convert from
CSA tagged RGB to a CRD destination; and then once it's normalized to
PDF to get tagged properly with the originally ICC version (from which
the CRD was created). I don't think this is a particular useful
workflow myself, and I think Adobe probably disregarded it as well
because it makes very device dependent PDFs which Adobe tries to avoid
unless it's one of the PDF/X-s.
If you want something like this, the solution is to tag everything or
tag only images. Any CSA's get converted to ICC profiles and tag those
objects. At print time, you select the destination profile and at that
time content is converted to CMYK. InDesign's PDF export will also do
what you are asking, and it's easier there just because there is no
distillation process. Everything stays PDF, in an ID PDF export, there
is no PostScript.
Yes, that is what I find so sad with the whole notion of PDF/X-1a is
that
all that's required to conform to the standard is the inclusion of
*SOME*
ICC profile, does not matter what that profile is (could be PANTONE
150lpi
SWOP). I mean if folks routinely tag their PDF/X-1a with the same SWOP
profile that is in the ICC resistry, without any regards to the actual
printing conditions the jobs is intended for, what good is it? It
means that
all CMYK jobs are intended for TR-001? That is a farce.
Pays to prepare your documents correctly. If you abuse the OutputIntent
in PDF/X-1a, the real fallout is just that your soft proof won't look
right. 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.
The more I read about PDF/X-1a and the more I have the impression that
the
inclusion of the OutputIntent was put in there to give some people good
conscience, knowing full well that, in practice, no one in the industry
bothers. The profile is just 'window dressing' and, in reality, all the
industry cares about is the assurance that all the data in the PDF is
CMYK.
It's metadata. Those who care and can make effective use of it can do
so. Those who aren't as sophisticated will ignored it, occasionally at
their own peril. But for the most part PDF/X-1a is very safe by itself,
the OutputIntent is just an extra piece of data that could have been
optional, but I prefer it required. If the job printed wrong, and it
was traced to the job only being soft proofed and approved on that
basis, and then determined that it was because the OutputIntent was set
incorrectly, there is an implicit liability by the party that created
the PDF/X-1a document as they set the OutputIntent incorrectly. I do
think it's good it's required, even if it gets abused.
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.