color management implementation, was: Embedding CMYK profiles
color management implementation, was: Embedding CMYK profiles
- Subject: color management implementation, was: Embedding CMYK profiles
- From: Chris Murphy <email@hidden>
- Date: Sun, 6 Jun 2004 16:51:41 -0600
On Jun 6, 2004, at 5:36 AM, mo wrote:
I don't know of many, if at all, any printers are "normalizing" files
by hand. The may be
doing some sort of conversion process in line with a RIP, but
converting files, in general,
is a liability. Printers want to print, and not do prepress. I've
heard it time and time
again, and when the crap hits the fan, and the fingers start to fly,
it's an easy solution
to say,.........I printed what you gave me. If it's screwed up, you
pay, not me.
What is the rule then? If it's PDF/X-1a it's clear that the numbers are
what are to be printed, unless the output device in no way matches up
with the OutputIntent. If that occurs, the job should be kicked back
for clarification on how it was prepared compared to where it's
supposed to get printed.
But if a printer is going to accept TIFFs, are they obligated to print
the numbers in the file? Or are they obligated to print the color
appearance defined by the combination of numbers and an embedded ICC
profile?
Differentiating between a tagged object that needs to be converted, or
needs to remain intact, is currently still a manual process if one is
not using PDF/X-1a. Even in the case of PDF/X-3 there can be a quandry
if it contains tagged CMYK content. Perhaps the embedded profile is
based on TR001 but it differs enough (in name, or other content) from
the profile the printer is using that it would cause repurposing to
occur when repurposing should not occur.
Part of what could be done with a URL based embedded profile scheme
would be simultaneous embedding of other metadata that would allow all
objects separated merely with different amounts of black generation to
be associated with a single colorimetric reference; and/or going
forward to allow for the automatic repurposing of CMYK while optionally
preserving channel purity, and black channel integrity including black
generation amount. This is not in the current architecture.
Not even the big houses want to be responsible. It's the American
way. When you have a
million impressions on a 3 million dollar job and you are some half
assed designer with
little experience in file creation, and has skated through your career
on your good looks,
you bet they're going to pass the responsibility onto someone else.
It's all a game of
liability.
The skill for designing things is entirely different than the skill for
creating a file that will print as desired. Designers design, they
frequently design stuff that won't print correctly because that's
simply not their skill set, and the applications don't force them to do
only things that are safe for their intended output. Transparency being
thrust upon all of us before it was ready for prime time, and for a
number of workflows still isn't, is an example.
We need to circumvent the stupidity by paving a wide enough road for
reckless drivers, with
lots of guard rails.
It's a narrow road to get things to print properly in most print
establishments.
P.S. Could you make sure your subject titles are correct when posting?
They're coming up with the digest name and # and it's hard to track the
thread.
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.