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 10:14:08 +0100
Jim Rich <email@hidden> writes :
>I thought that the meaning of remote proofing was that it had to do
with
>proofing an image or page being reproduced at a "distant or remote
site"
Right, but in stages like so,
- for simple PostScript forward rendering : none
- for simple PostScript forward rendering with ICC backend : if you
grit your teeth
- for simple PDF forward rendering with ICC backend : if you grit your
teeth
- for advanced PDF with forward and backward rendering through
OutputIntent : sure
>on a monitor or a printer.
For monitors : Karl Lang at one point played with the idea, Roger
Siminoff would know as he was product manager. In the same timeframe a
group of developers based in Cambridge offered a remote soft-proofing
solution which was enormously expensive. A perfume manufacturer was
claimed to have bought into the solution.
My personal view is that if corner dE co-ordinates of 4 or more on
mid-range CRTs are as common as I have found them to be, then a monitor
does not have the basic dimensional color stability that would allow me
and you to verify that any chart system large or small renders the same
at two locations. If one were to take this route, the monitor make and
model would have to be certified beforehand.
If the rendering capabilities of the interpreter are controlled, if the
spectrophotometer is calibrated and correctly certified, and if the
user sets the correct measuring condition in situations where the
instrument is not automatically configured through host software, then
for reflective surface proofing processes there are no basic hardware
problems. An average inkjet is more consistent from corner to corner
than an average monitor.
The monitor is a challenge and I don't know how to tackle it. We all
want to be able to work with remote soft-proofing, but nobody has an
idea of how we are supposed to do it, and maybe it's just a bridge too
far?
>I also thought that in any type of remote proofing scenario you
could send
>the remote site any type of file such as a tiff, PSD or PDF and use
the
>source files embedded profile and the remotes site will use the output
>devices destination profiles and some calculated luck to get a visual
match.
In the simplest possible case, you cannot just send a remote site an
RGB TIFF without specifying which CIE colors the device values should
reproduce.
The remote site cannot know what printing condition the forward
rendering is supposed to target, nor which forward (PC - RCBPC)
rendering is desired.
This brings in the issue of synchronizing device settings at the local
and the remote site. If both users know what they are doing, it should
work though IMHO.
You cannot send a PostScript or Encapsulated PostScript file because
strictly speaking both formats allow programming constructs outside the
Adobe Imaging Model.
(Early Freehand, CorelDRAW, Designer versions programmed into
PostScript what PostScript did not have and consequently crashed RIPs.)
You can send PDF because programming constructs are illegal, and more
specifically you can send PDF/X-3, if the instrument and the
interpreter are up to it.
I don't want to acknowledge that PDF generated with Distiller is
acceptable. I loose object level text management, I loose object level
color management, and Distiller is able to specify the wrong per-object
rendering intent. Tell me I'm wrong?
Question : Does the local and the remote device synchronization have to
be automated? And does automation have to be based on an open standard?
At one point I tried knock on doors to get the Adobe color settings
files implemented directly in iQueue, but that was another bridge too
far -:).
We can't have couriers carting around for all time, the courier is a
legacy phenomenon for simple PostScript forward rendering to a laminate
proofer. There has to be a better world than that -:).
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.