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 20:33:19 -0400
>
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.
Absolutely. Tagging is the way to go ... if and only one operates from a
well-behaved high-end pro dtp app like InDesign. 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.
>
ICC profiles do not exist in a PostScript stream.
Of course they don't. But they do in PDF.
>
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.
No question.
>
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.
Fair. And you know that there are still many outfit that refuses PDFs
prepared by anything but Distiller. That's my point. Distiller should not
deny the user of a CMYK workflow. 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.
>
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.
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.
>
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.
>
It's metadata.
It ends up being treated that way. So why bother in the first place?
>
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.