Re: Remote proofing and Thurber's aunt
Re: Remote proofing and Thurber's aunt
- Subject: Re: Remote proofing and Thurber's aunt
- From: Henrik Holmegaard <email@hidden>
- Date: Mon, 8 Mar 2004 09:19:49 +0100
On sxndag, mar 7, 2004, at 20:24 Europe/Copenhagen, Roger Breton wrote:
More and more, I equate 'remote proofing' with some 'PDF' flavor of
printing.
PostScript allowed image capture, page layout and print services to
take place in staggered schedules at separate sites.
PostScript is a forward rendering technology, that is, it is
output-oriented. The word simulation is not part of the PostScript
dictionary.
PDF has become a forward and backward rendering technology through the
OutputIntent. PDF knows _exactly_ how to spell the word simulation.
A rough and ready breakdown of issues might look like so,
- interpreter technologies ?
- instrument technologies ?
- first generation PostScript approach ?
- second generation PDF/X approach ?
- chart approaches ?
There are issues in how interpreters manage the mechanics of color
spaces designated as process and separation planes. For instance, spot
colors might convert to process colors in some interpreters, see the
Adobe support web.
There are issues with measurement technologies which do not ensure a
lower than delta E 1 instrument to instrument tolerance. As FOGRA
tightens tolerances the instruments must conform, political correctness
or no political correctness.
First generation PostScript approaches address the inability of
application software to cross-render at all / to cross-render all file
formats. So the approach does two things, (1) cross-renders and (2)
builds PDF.
For instance, if you first harmonize all objects to the same printing
condition in an iQueue hotfolder, stream PostScript to Distiller,
create PDF and cross-render in another hotfolder, you still need to
validate in Adobe or Callas software.
In a one-step workflow the interpreter would have to harmonize the
objects in the page to make sure the print and the proof are predicated
on the same ink limits and hence the same gamut, and do all the other
steps, too. I don't know about this one.
A variant of the above is PDF/X1a which to my way of thinking is for
the reprosauria. In this nature park for protected species the
behaviour is to send one ink limit to the press and another ink limit
to the proof, all the while talking about dots ?
A minimum definition of a proof is that all ink limits in the page are
harmonized for the intended printing condition, either before placing
in the layout or at the time of generating PDF or PostScript.
(A corollary is that the CMYK Working Space profile must have
symmetrical ink limits across all rendering intents. In case those who
favour PDF/X1a forget the fuss over asymmetric ink limiting four years
ago.)
So I would _not_ accept PDF/X1a as a remote proofing framework. I want
to know that placed objects are harmonized which means I want them
tagged and converted, and I want the same profile tested by all
involved to be embedded as OutputIntent.
I am not sure if I would want to / have to include screening
simulations alongside color simulations?
I am not sure what chart I would want to specify for certifying that
color rendering is identical on the sending and receiving proofing
system?
The confusion over interpolation-based LUT processing models is
allowing the proprietary proofing systems to have the field of contract
proofing to themselves. This is where Thurber's aunt comes in, that is,
if the user community is confused not about basic LUTs (a kerning table
is a LUT) but about advanced interpolation-based LUT processing models,
how does one show these people a way out of the confusion that stops
them from even trying to work with open systems interoperable,
instrument-based remote proofing ?
mixing and matching all kinds of source images Photoshop and
Illustrator
images, each having their own embedded profiles (sRGB, AdobeRGB,
TR-001,
ColorMatch, PhotoDisc),
The idea is that if the application software can't convert the channels
in all file formats (e.g. QuarkXPress), then if the interpreter is
fitted with an ICC frontend it can get the job done, but that does not
imply that the objects were harmonized.
at the time I try to print (proof) it all on my
printers this is not considered 'remote proofing' because the proofing
takes
place WHERE the document is assembled.
Right, User_1 and Location_1 and User_2 at Location_2 need to
self-certify that the render is identical in both cases. Color is only
part of this challenge, other parts are to do with the separation
planes in the interpreter, for instance.
I have the
impression that, as soon as I cross into PDF territory by exporting to
some
flavor of PDF standard supported by CS, that this is 'remote proofing'?
I would like to have a solid and sound argument for agreeing that
PDF/X1a is an acceptable platform for remote proofing. I don't see how
it can provide the checks and controls which are necessary, but that
may be because I haven't got it right ?
If I
email my PDF to a printer or a client and they try to generate
'proofs' out
of the PDF at THEIR END, then this is considered 'remote proofing'.
Right, but there needs to be agreement about what exactly the proof is
supposed to be a proof of, and what parameters are being proofed.
This maybe too simplistic a view but may not be far from a majority of
people's view on this List. I wonder, then, what's so special about
printing
or proofing out of Acrobat that makes it a case of 'remote proofing'?
Acrobat supports two PDF standards, but I am not sure both PDF
standards properly speaking support color proofing.
For the mechanics of rendering there is Acrobat and Callas software as
well as a test suite, but I'm still scratching my head over whether
they are really catch-alls.
I should re-read the above, but don't have the time.
Thanks,
Henrik
_______________________________________________
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.