What sort of print job (offset, ink-jet, digital,
other)? What sort of color proof? If no color proof, why not? (One of the
purposes of a color proof is to catch errors like this, isn't it?.) What
about some compromise on the reprint, like you pay for materials and he
provides the labor, etc. or you pay for the cost of the reprint but the he
issues you a credit against future business (at say $.10 to $.20 on the
dollar) for the cost of the reprint such that he keeps a customer and you
ultimately get your reprint for free?

You should have signed off a proof. If you told the
printer to go ahead and print without a proof then you are kinda stuck.

If the picture looked obviously bad then I would
question the printer on why someone didn't mention the picture looked bad.
But if the picture looked ok, they wouldn't know what it is supposed to
look like.

As Preston mentioned in his message you may be able to
work some kind of deal on a reprint.

It's going to depend on how big a print job it is and
how much the printer wants to keep your business.

We have one (repeat "one") customer who
wants to save money and doesn't get a proof. However, what they get
(final product) is what they get and they pay for it. No discussion.

Running a job without a proof is so abnormal for us
that I (upper management) sometimes have to intervene, despite written
instructions on the job ticket, to assure the press crews that it is
OK to proceed without a proof.

So, your verbal instructions are worth the paper on
which they are printed.

There were no phone calls so I assumed everything had
gone OK. Anyway,

turns out he converted the file to a TIFF but didn't
convert to CMYK. I needed to

use some lighting effects in PS and had set up in
Adobe 98. Needless the say

the prints turned out bad! They have refused to
reprint and want payment for

the job. Who is at fault here?

I would have to agree with others who have posted,
that the blame is primarily yours although the printer shares some of it.

This scenario has played itself out several times on
this list and dozens on others. The culprit is invariably Adobe RGB.
I don't favor that RGB definition anyway, but that's beside the
point. Anyone who uses Adobe RGB absolutely has to take the responsibility
to make sure that the next person knows, because if the next person doesn't
know and doesn't take action it will be a flat, washed-out disaster. With
other RGB definitions, the result wouldn't be nearly as bad.

We were first faced with this issue in, I think, 1999,
when Richard Kenward was victimized by a somewhat similar turn of events.
At that time there were some souls who thought that embedded profiling
might catch on as a workflow, so some people blamed the service provider.
Since then, the consensus on the list has been that most printers don't
even know what an embedded profile is because they've set up their systems
to ignore them completely. Hence, those who've experienced the
problem have found little sympathy here, because regardless of whether
printers *should* respect the Adobe RGB setting, the fact is they *don't*,
and people who expect that they will must accept the blame for the
inevitable result.

Wait a second guys. Are we to understand that the
printer sent the RGB file

to press without converting to CMYK at all, or did the
conversion turn out

poorly because the profile was ignored?

Yes, the printer sent the RGB file to press without
converting to CMYK at all.

I have now created a confirmation form to be sent out
with my artwork which includes space for "special instructions".
The form will be signed and faxed back to me so there can be no confusion
about instructions.

The printer has been contracted to produce a piece of
work. As part of the contract he has also *chosen* to accept:

1. An RGB file

2. A PSD file that was not ready for print

3. Data from a faulty computer

These are BIG warning signs to anybody who is prepared
to give the project a millisecond of thought. Each of these points requires
time (and therefore money) to deal with.

Accepting the job without agreeing additional fees
would be unprofessional. Accepting the job without the expertise to deal
with these issues would also be unprofessional.

But they did accept the job. And then they *allegedly*
screwed it up.

The printer needs opprobrium not a sympathetic, minor
*share* of the blame.

Hence, those who've experienced the problem have found
little sympathy here, because

regardless of whether printers *should* respect the
Adobe RGB setting, the fact is they

*don't*, and people who expect that they will must
accept the blame for the

inevitable result.

If the printer does not have the expertise to handle
the RGB data then they should *not* accept RGB data.

They had choices here: honour the profile, use their
expertise to apply something better, call the client and ask them what to
do - or ignore everything and screw it up.

The actual RGB space used is of no consequence
whatsoever. Failure to respect an RGB profile means that the printer is
*choosing* to *reinterpret* the image data.

Taking on all of this responsibility and then failing
to get the client to sign off a proof before committing the job to press is
an exceptionally unprofessional thing to do.

I see no reason for the commissioner of the work to
accept responsibility for such unprofessional conduct from a supplier*.

If the printer will only accept plates, then you are
being billed only for their press time and expertise at keeping the press
running to acceptable standards. If they accept RGB PSD data then, you are
being billed for their image manipulation, colour management, page layout,
prepress and press expertise. If it ain't up to scratch then don't pay for
it.

*Apart from the fact that both have opted to remove
prepress professionals from the production process and therefore get
exactly what they deserve...

Well, then he's an idiot or asleep at the wheel,
especially since you told him that the file needed conversion. Something
like this should be more than obvious on several levels in the work flow
without you even having to say anything. It's almost as if he wanted your
job to fail.

I'd 'politely' request that he take advantage of his
errors and emissions insurance policy to cover the cost of reprinting the
job at his expense. A law suit would get you at least half the money back
for sure, but it's probably not worth going through the aggravation of the
legal mill.

This is a tough one, and the answer is,
predictably...you probably both are to some extent. I've been on both sides
of the coin, as co-owner of a design company and as a prepress guy for the
last 13 years.

The printer should have a clearly defined policy of
having clients sign off on proofs. They should also generate a proof that
would be of good enough quality for you to feel comfortable signing off on
it, and they should then be responsible for matching that proof. If you
have any doubts or misgivings, you should ask for a press check to be sure
you are satisfied before the job is run.

There isn't quite enough information in your post for
us to know everything. Is this a printer that you've worked with before?
Were your expectations realistic; were they based on past experience with
this particular printer?

What you told him ("it just needs
converting") could be interpreted many different ways. Converted from
one color space to another? From one mode to another? From one file type to
another? Obviously that's where the breakdown in communication occurred.

My expectation as a client, and what I do in practice
as a service provider, is to call with any concerns to make sure what
occurred with your job doesn't happen. It's all about expectations; color
is subjective. What is acceptable to one client may not be to another--many
clients are very happy with the old "pleasing color". Did you
expect him to know what you wanted? Did he think he knew what you wanted?
Or do you think he just didn't care enough or didn't have the expertise?
Did you abdicate your control by agreeing somehow to bypass the proofing
stage? I think these questions need to be answered before a conclusion can
be drawn.

Bottom line is...if there wasn't a proof for him to
match so he knew what you wanted, you can't fault him. If he didn't match
the proof to your satisfaction, contact PIA (if he's a member)--they have
arbitration services, so maybe you can get some relief there. If it's just
a lousy looking job that you think he shouldn't have run looking that way,
stand your ground. And find another printer.

As a printer, it doesn't do us any good if clients
aren't happy. We eat jobs occasionally that we don't feel are our fault
because it's good customer service...and good business in the long run.

There have been a few angry, or at least indignant,
responses assigning responsibility to the printer, but the client does have
responsibility in the workflow as well. Not every printer uses color
management and many don't know how to handle profiles. Unfortunately, there
isn't a clear or published standard--yet--regarding this. People using
color management should know this as reality in the industry, and as a
practical matter should probably assume the worst. It usually happens.

The printer has been contracted to produce a piece of
work. As part of the

contract he has also *chosen* to accept: 1. An RGB
file 2. A PSD file that

was not ready for print 3. Data from a faulty computer

Accepting the job without agreeing additional fees
would be unprofessional.

Accepting the job without the expertise to deal with
these issues would

also be unprofessional.

If the printer does not have the expertise to handle
the RGB data then

they should *not* accept RGB data.

I see no reason for the commissioner of the work to
accept responsibility

for such unprofessional conduct from a supplier*.

...If it ain't up to scratch then don't pay for it.

Well... &$?!!*@!!, I agree with NONE of
this. If a designer sends an RGB file with clear instructions to convert to
CMYK, and the printers fails to do so, you have a legitimate complaint.
If you send a file with vague instructions to print it with no proof,
end of story, you take what you get.

Additionally, there could be more to this story than
we are being told. We get very few jobs saying "print my photoshop
file". More than likely (just surmising here) it was an RGB image
placed into some other layout program. When it was ripped, the RIP made its
own conversion to CMYK, hence color that the creator was not happy with.
Most RIPS do a "fair" CMYK conversion at best, since we all agree
that is not the place it should be done. As a printer, we don't take a job
apart piece by piece looking for RGB files, unless we are told to do so. I
could have the RIP stop, and not proceed converting and RGB image, but we
don't. It's only a problem if the client catches a color problem, IN THE
PROOF, that we, or they go back and fix it.

IMHO, this is a clear example of someone wanting the
printer to pay for a rookie's error. Most of the files we receive are
clean, professionally prepared and rarely require any extra desktop time.
We also get of lot of junk thrown at us that we are asked to, and do fix.
Then there are the files from the "experts" that think they know
everything. These are the ones that have the most problems, complaints, and
don't want to pay for something. I had one tell me the other day that
"he had been doing this for 2 years" and knew what he was doing.
I didn't even respond.

On this particular occasion I had no choice but to
give the printer an RGB PSD for reasons mentioned earlier in the thread.
The images I normally send out are ready to go to press, hence the
instruction to convert given to the printer.

I did not give the printer an RGB file thinking it
would print OK on press! There was a comminication breakdown.

It would be nice to know who initiated the
communication cited, and whether there was ever any mention, by anyone,
that the file was RGB.

It seems from the description of the communication
that you were more concerned with the format conversion than the color
conversion, leading the printer to associate the problems he was to call
about with the format conversion.

Unless it was a very unprofessional shop I can't
believe that RGB wasn't mentioned. In my experience, even shops that have
established RGB workflows internally want CMYK files when supplied, so
without any other specifics I would tend to think that somewhere in the
communication you'd said something to the effect that "rgb will be
fine", and maybe, "I do it all the time".

That there's no mention of asking to be provided a
proof also seems telling, I certainly would never want to go to press with
anything I cared at all about without seeing a proof I could trust or, at
the very least, knowing the workflow intimately.

From the surrounding circumstances its reasonable to
assume your hardware problems had you wait past the last minute, having the
job become a rush. If that's true, your priorities would now look to have
been time and file format.

With the provided information, I have a hard time
seeing the developing situation as one in which the printer would be likely
to have any real blame.

As someone who is a printer
and also usually just reads this list for the valuable information that
appears here, I wanted to give some observations. It seems to me that there
is not enough information here to properly decide the issue, however,
having been in this business since 1981 and having been involved in digital
workflows since the late '80s some things are usually true in printing.

A customer who gives you a
job based on no proofs in the quote, I assume no proofs in the quote
because the originator of this thread was not surprised that he was not
signing any proofs, means that the quality expectations of this project are
usually very low. Any mid to high level quality project would never be
quoted without proofs, in our case these include a final trimmed proof and
a full color contract proof. Furthermore, most printers will not even quote
any job, regardless of quality level without proofs being part of the
quote. It is only when a customer tells us directly that they do not want
to pay for proofing do we even consider it, and then only after the
designer signs a disclaimer that they maintain sole responsibility for
content and color. All we do at that point is RIP the file and print to
SWOP ranges for color. The type of work that we do in this category is
usually low-end direct mail crap that gets tossed out before making it into
most people's homes (thank god for our disposable society providing us this
employment).

Having said all that, our shop would probably reprint
the job for this customer at paper cost only or possibly no cost if we felt
we could salvage the relationship and move forward together as buyer and
vendor. As a printer I would not have allowed this job to process through
my shop without a proof once I knew the nature of the files I received. Our
goal is to print your project and make you happy with the result, in this
case that is not possible without first showing a proof. If the customer
refused a proof at this point, I would insist they sign a waiver removing
responsibility for quality. If I felt we would have a long relationship
with this customer, as I want with all our customers, I would probably
offer this proof free or reduced cost to show the importance of the proof,
and our ability to match these proofs.

Thanks for letting me rant a little, I hope I did not
offend anyone with these comments I just wanted to express a viewpoint from
a vendor as opposed to a buyer of printing.

A person sends a sketch of a house to a builder.
The sketch has dimensions in "units". The designer
does not specify whether the units are metric or English. A unit is
an arbitrary length chosen by the designer. The sketch has no
materials specified. The builder does not talk with the person
sending the sketch. The builder builds the house facing the wrong way
on the lot. The builder builds the house out of very weak materials.
The door is so low the person cannot enter the house. The first
wind that comes along blows the house down.

Whose fault is this?

When we change the context to another industry this
whole thing sounds bizarre. But this is the current state of the art
in the printing industry. We do this business by high craft and art.
Every job is custom. We have not matured to a level where we
use manufacturing methods that were developed more than two hundred years
ago. They started building guns with interchangeable parts at that
time. Before that time each gun was hand crafted. Each job was
custom. Each one was done using high craft and art. No two guns were
alike. You could not move a part from one gun to another.

When will the printing industry move to specifying
color on agreed international standards? When will the printing
industry move to tolerance color using agreed upon international standards?
When will we move to an objective way to specify what we want
manufactured? When will we agree on the language of our industry? It
is possible to do this today. The standards exist. The
measurement instruments exist.

"You must send a proof". This tells
the whole story. We have to send a maquette. An artists model.
We cannot just send numbers, because the numbers don't have any
device independent meaning in our industry.

When was the last time you saw a house builder with a
detailed model sitting on the construction site?

We will only change when we adopt manufacturing
methods. We need process control. We need understanding of the
physics of our process at a first principals level. We need standards
for specifying color and specifying the tolerance that is acceptable.
We need to agree on a page description language that covers all of
the results that we need to complete the job.

We all are at fault for using methods that are more
than 200 years out of date!!!

Now, I will wait for all of the replies that will tell
me about the faults with CIELab. I think these faults are small with
respect to the situation described at the beginning of this thread. I
believe that if the designer had a calibrated proofing method in his shop
(softproof or hardcopy) and had sent the data in a standard RGB space and
had ask for the printer to print to a tolerance of delta E of 5, he would
have gotten much closer than he did.

I hope all of us will be willing to spend some time
working on standards committees like SWOP, GRACOL, SNAP, ICC, etc.

OK, I will put my soapbox away now and go back to
getting some work done.

Ray

The opinions expressed here are solely those of the
author and not of the company he works for.

If that is really true, then the printer is 100% at
fault (again, unless the contract/agreement you signed stipulates otherwise
in a case like this). Relying on built-in, generic, in-RIP color management
to properly separate a job is asking for disaster.

practical matter should probably assume the worst. It
usually happens.

There are standards committees working on this issue:
CGATS (Committee for Graphic Arts Technologies Standards), and the ICC
which deals pretty much exclusively with the format of profiles.

Also, the various flavors of PDF/X are published
standards and all deal with the color management issue in different ways.
PDF/X-1a is CMYK only, fonts and images must be embedded, and an
OutputIntent specified. The OutputIntent is either an externally referenced
output process (like SWOP/TR001), or an explicitly embedded profile. For
PDF/X-3 is device color and device independent color (each object can be
defined by a profile), fonts and images are to be embedded, and
OutputIntent is to be specified.

It's not a good idea for you to approve something for
printing with an agreed upon proof, or agreed upon press behavior. You have
no idea what you're going to get, and if you enter into a contract to
purchase printed product without a proof, or defined press behavior that is
very, very risky business.

For the printer to engage in printing without a proof
is even riskier because he's usually not asking for upfront payment. It's
not reasonable for a printer to acknowledge this is not a prepaid job,
implying you will pay upon satisfaction of delivered product, and then say
you must pay no matter what.

Conclusion: a failure to communicate by both parties.
He probably heard "unless I think looks ugly, print it as is" and
you heard "print it unless I think think it look ugly, otherwise call
me." The sure form of communication is a proof. If you're going to
cheap out on a proof, these are the kinds of things that happen.

Resolution: the fair thing would be for both of you to
come to an agreement that neither of you are totally satisfied with.
Whatever his actual materials cost is, if you were to pay 1/2 of that would
hurt him and hurt you equally and hopefully there would be a lesson
learned. In reality, he's mostly on the hook unless you've signed some kind
of contract/agreement that stipulates otherwise, in cases like this.

has been that most printers don't even know what an
embedded profile is

because they've set up their systems to ignore them
completely.

Hence, those who've experienced the problem have found
little sympathy here,

because regardless of whether printers *should*
respect the Adobe RGB setting, the fact is they *don't*, and people who
expect that they will must accept the blame

for the inevitable result.

It's a classic case of walking in a cross walk,
assuming the Mack Truck is going to stop before smearing the pedestrian
onto the pavement for the next two blocks. The customer can be in the
right, and still get creamed. Don't make assumptions. (And that goes for
printers too.)

We all are at fault for using methods that are more
than 200 years out

of date!!!

Pretty much, yeah. But even today there are root beers
made in small batches by hand. Regular icky beer too. There will always be
room for truly unique services and products.

Now, I will wait for all of the replies that will tell
me about the faults

with CIELab. I think these faults are small with
respect to the situation

described at the beginning of this thread. I
believe that if the designer

had a calibrated proofing method in his shop
(softproof or hardcopy) and had

sent the data in a standard RGB space and had ask for
the printer to print

to a tolerance of delta E of 5, he would have gotten
much closer than he

did.

This is asking a lot from a printer that apparently
didn't even preflight the job, and ended up submitting it to the whim of
PostScript color management in who knows what RIP doing who knows what kind
of conversion. It might have taken him months to do delta E calculations on
every unique color in a given image.

Also, we should be using delta Ecmc as a minimum.
Delta E76 is really easy to use but it's also really flawed (underestimates
the difference in neutrals and yellows, underestimates in red and blue.)
I've been using delta E2000 lately, which is supposedly even better than
cmc.

Well... &$?!!*@!!, I agree with NONE of
this. If a designer sends an RGB

file with clear instructions to convert to CMYK, and
the printers fails to

do so, you have a legitimate complaint.

Glad we &$?!!*@! agree then.

The client sent an RGB Photoshop file. How are you
going to print that without making two or more conversions to the file?

By choosing to accept this type of data you are
implying that you have the expertise to offer the additional services of
Photoshop work and RGB to CMYK separation.

If you have those expertise then you can usually spot
the stuff which is totally out of gamut and make sure that borderline stuff
is proofed and agreed before committing to a print run.

You don't just run it and then hold out your hand
expecting to be paid.

If you send a file with vague

instructions to print it with no proof, end of story,
you take what you get.

Dan's quoted version of the post didn't mention that
the client had ordered the print job to go ahead *without* a proof -
although the original poster is rather vague on this point.

If he did then that was a stupid thing to do. However,
the supplier should have *insisted* on a proof being produced because of
the dangers associated with accepting RGB PSD data - and the possibility
that they won't get paid if it goes wrong.

Additionally, there could be more to this story than
we are being told.

That's why I used the word *allegedly* in my post.

We get very few jobs saying "print my photoshop
file". More than likely (just

surmising here) it was an RGB image placed into some
other layout program.

When it was ripped, the RIP made its own conversion to
CMYK, hence color

that the creator was not happy with. Most RIPS do a
"fair" CMYK conversion

at best, since we all agree that is not the place it
should be done. As a

printer, we don't take a job apart piece by piece
looking for RGB files,

unless we are told to do so. I could have the RIP
stop, and not proceed

converting and RGB image, but we don't. It's only a
problem if the client

catches a color problem, IN THE PROOF, that we, or
they go back and fix it.

IMHO in-rip separations are crap. And I'm dubious that
you've got a RIP that can handle layered PSD data. RGB data should be
caught during flight checking and the job stopped until the client either
supplies new images or pays you to do the conversion. Proofing the job when
you know it is incorrect is a waste of everyone's time and a waste of your
client's money.

IMHO, this is a clear example of someone wanting the
printer to pay for a

rookie's error. Most of the files we receive are
clean, professionally

prepared and rarely require any extra desktop time. We
also get of lot of

junk thrown at us that we are asked to, and do fix.
Then there are the files

from the "experts" that think they know
everything. These are the ones that

have the most problems, complaints, and don't want to
pay for something. I

had one tell me the other day that "he had been
doing this for 2 years" and

knew what he was doing. I didn't even respond.

We'll have to agree to disagree on this. The only
things that are *clear* from this scenario are that there are plenty of
businesses around that find it easier to proof and print rubbish than to
pick up the phone and talk to a client.

If the guy is both a rookie and having problems with
his system then one might think that:

1. he deserves a little helpful handholding, or

2. deserves being told politely to take his difficult
job elsewhere

Instead, he gets a crap print job, a bill and a bunch
of industry professionals snickering that he deserved everything that he
got.

Maybe it's just me, but I don't see this working as a
sustainable business model. And, as I mentioned in my post, as the prepress
industry is disappearing one would assume that printers are going to be
dealing with more and more *rookies* with iffy RGB Photoshop images.

You never know, being a little more helpful might be
advantageous... Or maybe I'm just a pre-press guy who fancies being a
customer relations consultant this week :-)

times to chime in but this is it - to suggest legal
action - give me a break!

Hey Dan! Who suggested legal action? I said it was an
unwise thing to consider!

THE GUY DID NOT SEE A PROOF - TIS BOTH THEIR FAULTS!

A printer who runs a job and doesn't look at his
output is a fool and a hack. Bells should've gone off in his head several
times on this one. From the sound of it, the job was a total mess, and now
he wants payment. If it were my shop, we'd have to eat the job because none
of my customers would pay the bill for a crap. On the other hand, if it
were my shop, this kind of thing doesn't happen because we preflight every
image and we either tell the customer what's wrong or we charge to fix it.
Turning out bad work and blaming the customer isn't an option. Especially
when the customer flagged the job with a request for special attention.

CLIENT FOR NOT ASKING, PRINTER FOR NOT INSISTING!

The customer asked for the printer's help. The printer
agreed but didn't follow through.

Let them both learn a lesson and go on - shame on you
for suggesting

legal action - and it is errors and omissions, not
emissions.

Again, who suggested legal action? Sorry for the typo.
I do know better - I've been in this sorry business over 30 years. Should
be sued for my error on omission?

These are BIG warning signs to anybody who is prepared
to give the project a

millisecond of thought. Each of these points requires
time (and therefore

money) to deal with. Accepting the job without
agreeing additional fees would

be unprofessional. Accepting the job without the
expertise to deal with these

issues would also be unprofessional.

Very correct in principle. In real life, the printer
was confronted with a young, inexperienced client (Alain has given me this
info offline) who had an emergency over which he was no doubt very upset.
The idea that under the circumstances the printer should want to try to
help and not want to charge extra doesn't sound unprofessional to me.

"Every few weeks, some color discussion group
features wailing and gnashing of teeth on the part of a user of Adobe RGB
who was foolish enough to pass an RGB file on to a service provider who had
never heard of Adobe RGB and had all color management turned off, thus
guaranteeing a nearly colorless result. The [Conventional Color Management
Wisdom] waxes wroth when this occurs. The service provider is called all
kinds of names, great sympathy is expressed for the victim, other service
providers are warned that resistance is futile, and everyone waits for the
next victim to fall into the trap so that the fun can begin again. The
practical person, however, accepts the world the way it is. For better or
worse most service providers have declined to learn much about this
methodology."

This was written three years ago, by which time it had
become apparent that the idea of honoring embedded profiles from strangers
was going noplace. There was no need to include it in the most recent
edition, because, except in the minds of most most extreme of color
management zealots, the issue is dead--as many posts to the group have
indicated, the topic is so far below the radar screen of most printers that
they couldn't even tell you what a profile is.

It's pointless to argue right or wrong here. The facts
are, far more so even they were in 2000, that if you expect the service
provider to act on an embedded profile, you're asking for what happened to
Alain to happen to you. If it *does* happen, then you can have the great
fun of blaming the service provider on this list or elsewhere. Personally,
I think it's more fun to have the job done right and forget about the
politics.

It's a classic case of walking in a cross walk,
assuming the Mack Truck

is going to stop before smearing the pedestrian onto
the pavement for

the next two blocks. The customer can be in the right,
and still get

creamed. Don't make assumptions. (And that goes for
printers too.)

Yes, I feel like I'm about to walk out in front of a
truck whenever I deal with a printer too. It shouldn't be that way.

Of course, in this event the dead pedestrian's estate
is entitled to an award for his untimely death. In our case, the client's
file has been "smeared" and the driver of the Mack truck, our
printer, still wants to get paid. Just because most printers don't respect
profiles, it doesn't give them the right to print junk. Shouldn't they at
least look and question if they're not going to go by the rules of the
road?

Then Dan Margulis wrote:

It's pointless to argue right or wrong here. The facts
are, far more so even

they were in 2000, that if you expect the service
provider to act on an

embedded profile, you're asking for what happened to
Alain to happen to you.

But we ARE arguing right and wrong here, aren't we?
Why shouldn't we expect printers to respect profiles when they agree to
accept RGB files? Everyone agrees that none of this would've happened if
the profile had been observed, so why is it right to throw it out?

Personally it seems pretty simple to me. The printer
agreed to do the work and accepted a RGB file.

It wasn't reasonably close to customer expectation. I
wouldn't pay (the full amount anyways). Try to work out what is fair
and if he isn't open to finding an equitable solution go elsewhere.
Don't pay dime one until you receive acceptable output.

But we ARE arguing right and wrong here, aren't we?
Why shouldn't we expect

printers to respect profiles when they agree to accept
RGB files? Everyone

agrees that none of this would've happened if the
profile had been observed,

so why is it right to throw it out?

I agree! It1s a shame so many printers heads explode
when they get an RGB file. Worse, so many haven1t a clue how to make a
conversion. If they are going to accept RGB data, they better get hip to
embedded profiles and how to make a good conversion. Otherwise don1t accept
them.

More reason Photographers and the like should take the
conversions out of the hands of these people. They know what color the file
should be better than anyone pushing files though a system, they deserve to
be paid to convert and edit if necessary the file in output space. They are
the new group producing the RGB data anyway (the number of images from high
end CMYK on the fly scanners is dropping like files and in fact film is
becoming a less used media every day, replaced by cameras that only produce
RGB data).

Provide the printer a file in output space and just
have them crank it out. It1s been done this way for years and years in the
photo labs by and large. They don1t open or mess with the files. They are
not qualified to anyway. Pass the numbers to the output device and leave
the data alone. OR if you are going to mess with the data, you better be
dame sure you have a calibrated and profiled display and know how to deal
with embedded profiles. Despite what Dan and company will tell us about the
failure of embedded profiles, the fact remains that if you get a file which
is nothing more than 11s and zero1s and have NO meaning without a profile,
you simply have NO business messing or altering with those numbers unless
you know what they mean. And they have no meaning without a profile. It1s
as simple as that.

I may be in a somewhat different situation from most
of you in that I am a buyer of printing services and could not run a press
with a manual.

However, I am in the business of buying things for
resale (rare books) and have been doing that for 35 years. I use the same
process for buying printing as I do for buying books. I try really hard to
work with the seller so that they want to help me; have confidence that I
will be a repeat costumer for a fair (not always the lowest) price, and
that I will not try to get something extra or a bonus every time we do
business. In return, I want them to care that the job be done well rather
than tricking me to some obscure specification that gets them off the hook
legally but is clearly no good.

I have been using the same printer for several years
and most of the press and pre press and driver folks know us and their
service has been wonderful. I pay my bills on time and in full. I have had
many issues, problems, and technical questions over the past many years but
they have been helpful, supportive, and willing to run tests and even send
people to my office (home) to help calibrate. When there have been serious
problems I have not screamed but asked for help and they have sent staff
and management out here and we have gone over press sheets with loups, etc.
to reach an understanding of what I want and what they can do.

The point being, think of your printer as part of your
team not an adversary. On the other hand, if you are the printer, try to
make the client an ally. So much of what I read about this very important
thread sounds like war rather than collaborative efforts. In general, I try
not to buy from adversaries since it ends up working poorly and whenever
there is a problem there is a fight not an attempt to solve it to
everybody's satisfaction. Of course, I want the press people to look at the
run and if it is obviously wrong, then stop and call me. I always give a
24/7 telephone number and try really hard to convince them that I would
rather be called than get a messed up job. I try always to tell folks that
"better is better than quicker."

The impression I get is that the relationship between
printer and printee is wholly adversarial and take no prisoners. Is that
really how it is out there in the world and am I just lucky here in
Virginia?

This was written three years ago, by which time it had
become apparent that

the idea of honoring embedded profiles from strangers
was going noplace. There

was no need to include it in the most recent edition,
because, except in the

minds of most most extreme of color management
zealots, the issue is dead--as

many posts to the group have indicated, the topic is
so far below the radar

screen of most printers that they couldn't even tell
you what a profile is.

Dan, I'll make a point of reading all you write on
Photoshop retouching because I have the utmost respect for your skills and
knowledge.

But I take your views on colour management with a
large pinch of salt.

Raw RGB data is meaningless. It's like supplying an
orchestral score without a time signature or any of the above and below
stave instructions that give the music it's feeling and emphasis. Sure, you
can make out the tune - but nobody's going to pay to listen to it.

If you only have one output device and you are the
final destination for the image then you can be in the comfortable position
of printing it and telling the client to screw themselves if they don't
like it.

We don't have that option. We output in RGB and/or
CMYK and then move the data on to other suppliers.

Closed-loop is not an option for us. We wouldn't use
it even if it were because the next supplier in the line will soon spot
that we have adapted the image to suit our favourite device (no matter how
awful it is) and thereby degraded it for anybody else who needs to use the
data.

A simple colour tag means that I see pretty much what
the client saw on their screen and get to use it as a basis for my
separation and enhancements.

Ignoring it means that I have to re-invent the wheel
every time I open a new image. I also needlessly risk getting it wrong and
then wasting time, materials and getting into a needless argument at
billing time.

What is the point?

My feelings are that many suppliers are reluctant to
get into colour management because it requires them to:

1. educate themselves

2. purchase calibration devices

3. maintain strict production controls

Maybe we should meet up at the Heidelberg hall at
DRUPA next year and you can introduce me to the press guys that recommend
operating their presses without colour management?

You claim: "the topic is so far below the radar
screen of most printers that they couldn't even tell you what a profile
is".

So what's new? There are loads of idiots around who
think that owning a good press makes them a good printer. Criticising and
publicising piss-poor printing will get the business moving to people who
can do a better job.

I guess since none of us were there as material
witnesses to what exactly was said, or took place. Its one of those cases
of don't get your eye poked out for the finger pointing ordeals. Sounds
like a case for Judge Judy.

And... for all the sayers of "everyone makes
proofs"... not always true. Hard proofs at least. We have some very
high end 4-color real-estate work we do on a weekly basis. Job comes in at
5:00pm, and we're on press by 8:00pm. We run standard densities, and OK the
jobs by the color bars only. The job delivers to the mail house at 8:
00am the next morning. Usually 8 to 12 different card versions, 15 to 25M
per card. There is no time for hard proofs, or time for client approvals.
We make hi-res monitor proofs and go. We put a lot of trust in the file
provider, and they put trust in us. The rules are simple, they are
responsible for supplying CMYK, hi-res, images, bleeds, and limiting fonts
to a pre-approved "pool" of about 50 different fonts. We are
responsible for trapping, ripping the files, and imposing on the forms for
the right card to back up the right card. In over two years of doing this
particular job, on a weekly basis, printing over 1000 different cards, we
have had 2 cards that had to be reprinted. Both due to RGB images, that the
client let slip by, as did we. They paid to have them reprinted. To them,
its far cheaper than the costs of contract proofs on everything, and the
added time to make them, and get them approved. Certainly not recommended
S.O.P. for all everyone, but we do have some clients we can do this with.

But I take your views on colour management with a
large pinch of salt.

Thanks god Chris and I are not the only one1s on the
list <g>. Off list, that1s a different story.

Raw RGB data is meaningless. It's like supplying an
orchestral score without

a time signature or any of the above and below stave
instructions that give

the music it's feeling and emphasis. Sure, you can
make out the tune - but

nobody's going to pay to listen to it.

It1s like supplying the orchestral sore upside down
and backwards.

The analogy I give to photographers is this. I1m going
to supply you with an unlabeled box of 4x5 film in which you will find a
single sheet of 4x5 film with no notches. Your job is to expose and process
this sheet of film. That1s virtually impossible to do since the user has no
idea if the film is Positive or Neg, or what ISO the film is. User has no
idea how to expose or process the film. Now label the box 3VPS III2 (the
profile) and you can do the job. The label on the box didn1t change the
content of the film one lick. Neither do profiles. But they do provide
critical information.

If you only have one output device and you are the
final destination for the

image then you can be in the comfortable position of
printing it and telling

the client to screw themselves if they don't like it.

You have to remember the background of so many who
don1t understand profiles which is exactly what you describe. It goes back
to that old fashion idea of working by the numbers only. Great if you KNOW
the numbers for the device you plan to print to. And in the old days, that
was a very viable workflow since there were so few devices (some press in
house) that you were going to target. Today that1s simply not viable for a
vast number of people. I want CMYK and RGB numbers from a file to output to
a press, an Epson, a Lightjet, an Iris etc. No one can juggle all the
correct numbers for so many devices. In fact, with the vast number of
images coming from digital cameras and end user scanners in RGB, who can
possibly control the input numbers without profiles?

We don't have that option. We output in RGB and/or
CMYK and then move the

data on to other suppliers.

Yup. And that1s NOT going to change. If anyone thinks
it is, they should also pray for type setting to come back too.

Closed-loop is not an option for us.

You and a huge number of users. And that grows all the
time while closed loop shrinks.

A simple colour tag means that I see pretty much what
the client saw on

their screen and get to use it as a basis for my
separation and

enhancements.

Isn1t that a nice thing! Unless you like to work with
totally ambiguous color that doesn1t appear correct anywhere. For those
people that like control for themselves only and like to keep things closed
loop and behind closed doors, this is scary stuff. For the rest of us, it1s
a wonderful way to work.

Ignoring it means that I have to re-invent the wheel
every time I open a new

image. I also needlessly risk getting it wrong and
then wasting time,

materials and getting into a needless argument at
billing time.

Look, when your job is to produce 2-3 proofs at a
clients expense to nail the color, what you propose is heresy!

1. educate themselves

What, do something different? Shocking.

2. purchase calibration devices

I think that1s a lesser issue since most of these
people have decent budgets (Presses and proofing devices are pretty
expensive. CMS hardware and software is not in within the big picture.

3. maintain strict production controls

Oh boy, that1s a big one!

You claim: "the topic is so far below the radar
screen of most printers that

they couldn't even tell you what a profile is".

You have to listen to this year after year with no
statically data to back it up before you start to ignore this. You hear
such statements as if they are fact but you never get any empirical data
other than what appears to be a feeling or belief. Now, I can tell you that
according to a recent report of the TWGA, 63% of graphic arts users are
Applying Color Management. Did I pull this out of my-you-know what? No,
here's a URL to check out:

http://members.whattheythink.com/news/newslink.cfm?id=
10627

Even if we discount the eye-balling part of the
article, we have to consider the displays are calibrated in some fashion
and that some descriptor of the numbers have to be in place or what all
these guys are seeing is science fiction. The fact that 63& admit to
using color management of some kind is telling in itself.

Even if we say that more users are not using CMS than
are, the report leads me to believe that the scales are turning the other
way, not the opposite as you would believe listening to some non backed-up,
"ear to the ground" opinion.

Very correct in principle. In real life, the printer
was confronted with a

young, inexperienced client (Alain has given me this
info offline) who had an

emergency over which he was no doubt very upset. The
idea that under the

circumstances the printer should want to try to help
and not want to charge extra

doesn't sound unprofessional to me to me.

The printer did not stipulate any requirements to
accepting the file. He accepted the file with the condition that it needed
to be converted. Any monkey or house plant can do: Image>Mode>CMYK
Color, but it takes someone with a certain level of competency slightly
higher than a monkey or house plant to ensure a good separation is being
made. Since he accepted the RGB file "convert to some crappy
CMYK" is inherently not an option, yet this printer took it by
submitting the file to the whim of color management in his RIP.

It was dereliction of duty for him to do this, and
amounts to sabotage of the job. He could have done no worse had he
intentionally or even "accidentally" dragged the whole job
through a fifth color made of dog crap.

It's pointless to argue right or wrong here. The facts
are, far more so even

they were in 2000, that if you expect the service
provider to act on an

embedded profile, you're asking for what happened to
Alain to happen

to you.

You know why? Because there is a culture of
irresponsibility whenever those responsibilities are not clearly defined
and enforced. If a printer were to ignore an embedded font, there would be
a conniption fit on all sides and obviously the printer would be at fault.
If the printer is going to accept RGB files, they are under obligation to
honor an embedded profile. If the embedded profile is wrong for some
strange reason, it's the customer's fault, just like if they'd embedded the
wrong font.

And in Alain's case, it has nothing to do with
embedded profiles. The printer not only ignored the embedded profile, he
assigned and used a totally different profile by sending it off to his RIP
- where the Adobe RGB profile was ignored, and a generic source and
destination were used to convert his job. I don't see how you can blame
this on embedded profiles because it's TOTALLY unrelated.

A) One definition of quality is, "Meeting or
exceeding customer expectations". Were the customer expectations
fully communicated and understood?

B) One of the participants in this thread referred to
"rules of the road". Does anyone know where can I get a
copy of these rules? How many people know these rules?

C) I feel sorry for those who believe that their
relationship with their printer must be adversarial. As a printer
since 1959 (starting in that paragon of friendship, NYC), I can assure you
that long-term relationships are not adversarial. I cannot remember
one customer/supplier relationship which has been both long-term and
adversarial. This includes both sub-contractor and customers who have
a wide range of expectations and abilities (but excludes unavoidable
relationships, as with a monopoly like the old Ma Bell).

This was written three years ago, by which time it had
become apparent that

the idea of honoring embedded profiles from strangers
was going noplace. There

was no need to include it in the most recent edition,
because, except in the

minds of most most extreme of color management
zealots, the issue is dead--as

many posts to the group have indicated, the topic is
so far below the radar

screen of most printers that they couldn't even tell
you what a profile is.<<<

I am curious about something here. If accepting files
in an RGB space, such as Adobe RGB, with the profile embedded is so far
below the radar for printers why is there a very pronounced trend on the
part of the magazine publishers to PREFER Adobe RGB?

I participated in the meetings of the DISC committee,
a working group of the IDEAlliance - the folks behind the GRACOL specs. The
work of this committee was to establish standards for accepting digital
files for their editorial content. You can go to http://www.disc-info.org/
and see that Adobe RGB is specified as the preferred color space.

How does that fit with Dan's statements? Seems to me
there is a disconnect here, can anyone shed some light on this?

Dennis Dunbar asked, "If accepting files in an
RGB space is so far below the radar for printers...why is there a...trend
on the part of magazine publishers to prefer Adobe RGB?"

One possibility:

The last count I heard was that there are about 36,000
printing establishments in the U.S. Printers with the capabilities to
print magazines and major publications are a relatively small number.

From what I've seen of the discussions here, my
intuitive feeling is that most on this list will not be going to a printing
company capable of printing major publications/magazines. The
"smaller" companies will have as wide a range of capabilities and
operating philosophies as the range of their customers' expectations.

I have been reading these threads for a few days and
there must be something in the water that makes everyone so tense.

Many of us on this list can and do make ICC based
color management work everyday for photographic and pre-press workflows.
And it is a plain fact that Color management works. It is not fool
proof and it is not perfect, but then again, neither is going by the
numbers. Color calibration is hard, but profiling had made getting
calibrated easier.

Oh yea (for those of you that might not know this), if
you use any recent version of Photoshop you are using profiles.

Another reality of using profiles is that if you use
them with a skilled by-the-numbers-person you get the color optimized
quicker and more efficiently.

A bottom line issue is that, if you get educated in
using profiles and then get some experience you can make them work to save
a business money.

Printing businesses are in financial straights these
days, they should pay attention and learn how to save a buck using
profiles.

Based on this thread, I dare say that if the client
and printer had a better communication channel and the printer was paying
attention to some fundamental profile issues each party would not be
bickering over it.

This hits the nail on the head. As an artist, and as
the chair of the APA Digital Committee I've been seeing the same arguments
and fears being expressed by both the photographer/artists and the
printers.

In the "Real World" we're all part of a
larger team. Images are not tangible things any more until they are
printed. This means that photographer and printer MUST work together or
disaster will happen followed very closely by finger pointing and the like.

When there is not time to dot the i's and cross the
t's we need to be even more certain that there is clear communication. To
what extent could this have prevented the problem in the first place? My
bet is the current discussion would be unnecessary if the printer and the
client had both taken the steps needed to be certain they knew what needed
to be done and what was expected.

I have been reading these threads for a few days and
there must be something

in the water that makes everyone so tense.

Sorry if my post appeared *tense* - it wasn't supposed
to.

I take on new working methods if they fulfil two
simple criteria:

1. Give a better result than we were getting prior to
adopting it

2. Make things easier for us to produce a good looking
image

Using transparent colour management fulfils both
criteria. This is no easy task when we are mixing and matching data from
in-house digital cameras, drum and CCD scanners and/or whatever we are sent
by the clients.

This stuff can then be proofed in RGB to Pictro or
wide gamut inkjet or in CMYK to press-simulating inkjet queues or analogue
film and Cromalin.

Colour management makes running all these devices and
getting a match between them much easier than it was when we were trying to
do this by eye.

Time saved can be spent making that image stand out
from the page instead of only having just enough time to meet the minimum
standard of a reasonable match.

Dan can call me a zealot if he wants. I seem to
remember my boss calling me the same thing when I resigned from a highly
paid job in typesetting to set up my own business with a Mac II (with
Xpress 1 point something or other and Aldus FreeHand) and a LaserWriter
back in 1990.

We really worked by the numbers back then - CORA on
Apple II workstations, a display full of green text and waiting for the
galleys to be imaged by a Lino 202. <m[x], f[x], h[x], l[x]>The quick
brown fox jumped over the lazy dog...

WYSIWIG was treated like ICC Profiles - unnecessary
for us real pro's that knew the numbers :-) Shame the clients were so
pissed off about being charged for all those wasted galleys when their mark
up was out by an em or two but the operator ran it regardless.

A simple colour tag means that I see pretty much what
the client saw on

their screen and get to use it as a basis for my
separation and

enhancements. Ignoring it means that I have to
re-invent the wheel every time

I open a new image. I also needlessly risk getting it
wrong and then wasting

time, materials and getting into a needless argument
at billing time. What is the

point?

What your personal workflow choices have to do with
the subject of the present thread I don't know. If you're saying that you
automatically honor all embedded profiles and execute conversions based on
them without the client's knowledge, and then you eat the cost of the job
if they don't like the result, that would be relevant.

My feelings are that many suppliers are reluctant to
get into colour

management because it requires them to:

1. educate themselves

2. purchase calibration devices

3. maintain strict production controls

An interesting speculation that has nothing to do with
the thread. Whether people are educated, or what equipment they own, or how
strict their process control is, all have zero relation to the question of
whether to respect embedded profiles from strangers. Service providers
nearly unanimously have decided not to do so. One has to assume that at
least *some* of them are well educated, own calibration devices, and have
reasonable QC procedures.

Maybe we should meet up at the Heidelberg hall at
DRUPA next year and you

can introduce me to the press guys that recommend
operating their presses

without colour management?

To what end? "Color management" is
irrelevant to this thread. All printers manage color. The question
pertinent to this thread is: do you recommend making automatic conversions
based on embedded profiles in files supplied by total strangers? And if you
do, do you recommend eating the entire cost of the print run if it turns
out that this was the wrong thing to do?

You claim: "the topic is so far below the radar
screen of most printers that

they couldn't even tell you what a profile is".
So what's new?

Nothing. The idea that embedded profiles are a viable
way of exchanging documents between strangers has been a dead issue for at
least three years. The argument might have been made in 1998 and 1999
but the market has long since made its decision. Trying to hide this by
saying that "ICC color management" has been widely adopted is to
indulge in the Andrew Rodney school of extrapolation. It's as if we were to
ask the printers at DRUPA whether they admired President Bush's decision to
abstain from alcohol, in view of his past problems with it; and if they all
answered yes, to come back and say that they unanimously supported every
one of his actions in Iraq.

Responsible printers try to work with the limitations
of their clients. Responsible clients try to work with the limitations of
their printers. There is no need for this continual debate. The question is
not how printer *should* operate but how they *do* operate. Those who are
interested in having their jobs screwed up, and having adversarial
relations with their printers, do things like surround their images with
large black solid areas, or bust small three-color type out of a
contrasting background, or stay away from GCR in areas where maintaining
neutrality is important, or rely on printers to interpret embedded profiles
correctly.

Those who are more interested in getting quality work
done in a reasonable timeframe without undue aggravation avoid these
practices.

embedded profiles and execute conversions based on
them without the client's

knowledge, and then you eat the cost of the job if
they don't like the result, that

would be relevant.

I feel like we've entered the Twilight Zone. Why is it
that absurd ideas like this are relevant, and logical ones like holding
parties accountable for their respective responsibilities isn't? Dan,
you're basically saying that because most printers don't know what they're
doing in regards to RGB and embedded profiles, and even if a printer
doesn't preflight the job but accepts responsibility for printing it,
that the customer is the party in the wrong if the job comes out bad
because "they should have known better." That's lunacy, and
you're only helping to perpetuate such lunacy.

To what end? "Color management" is
irrelevant to this thread.

Oh really? YOU were the one who brought it up to begin
with by blaming Alain's problem on Adobe RGB being embedded. Apparently
embedded profiles are not a color management issue as far as you are
concerned.

Nothing. The idea that embedded profiles are a viable
way of exchanging

documents between strangers has been a dead issue for
at least three

years.

That's insane. It's like saying because only 5% of the
market uses PDF/X-1a that it's not a viable way of exchanging documents.
You prefer a haphazard workflow where no one has any responsibility at all
except to assume the printer is an idiot and the customer needs to have end
all be all skill in order to prevent the printer from destroying a job; and
if the customer can't do that, then it's their own damn fault because they
should have known the printer was just itching to do something stupid. What
an amazing set of assumptions and pessimism.

The question is not how printer *should*

operate but how they *do* operate.

Yeah, it's all clear now. You've basically given up on
printers and printing. You assume they aren't ever going to change in any
appreciable quantity, and yet there are ever increasing numbers of European
printers that do follow things like standards and not only use embedded
profiles but practically require them (that's where the major push for
PDF/X-3 came from). No no, don't hold them responsible for anything they
should do or even anything they say they will do; ultimately the printer's
customer is totally responsible for how their printer actually behaves.
That's simply brilliant.

Those who are interested in having their jobs

screwed up, and having adversarial relations with
their printers, do things

like surround their images with large black solid
areas, or bust small

three-color type out of a contrasting background, or
stay away from
GCR in areas where

maintaining neutrality is important, or rely on
printers to interpret embedded

profiles correctly.

Everything is a bad habit except the last one by your
own admission. You admit they use profiles incorrectly and yet you are
unwilling to hold them accountable, instead you expect their customer to
shoulder that burden entirely. Crystal clear, Dan.

had both taken the steps needed to be certain they
knew what needed to

be done and what was expected.

I mostly agree with this in concept, but in this
particular case there is that one little detail. The customer qualified
their file, although perhaps not fully. But the printer either didn't
preflight the job, or did but decided to run it anyway; and the way they
decided to run it is widely known on the printing side of things to cause
problems.

The customer isn't in a position to tell the printer
how to convert the file to CMYK, or the customer wouldn't be providing an
RGB image in the first place. It was the printer's choice to use quite
possibly the worst method known to convert a file. If the printer had said
"oh yeah we can do that, the RIP takes care of them" that's
*clear* communication but it's not something the customer is qualified to
challenge. The job still would have been a mess. This is a case of a
printer simply doing the wrong thing, as the story has been told.

A simple explanation needs to be developed and widely
distributed on how

to use Image Mode Assign and Image Mode Convert.

This would alleviate many of the "who's at fault
issues".

HA! This is the funniest reply yet.

Most of those who don't already know about it, don't
want to. I've had people yell at me for merely mentioning profiles. These
are pre-press "professionals" and printers who just want to dig
their heels in. They're also the worst hacks that I've ever run into in
this business.

The customer isn't in a position to tell the printer
how to convert the

file to CMYK, or the customer wouldn't be providing an
RGB image in the

first place. It was the printer's choice to use quite
possibly the

worst method known to convert a file. If the printer
had said "oh yeah

we can do that, the RIP takes care of them"
that's *clear*

communication but it's not something the customer is
qualified to

challenge. The job still would have been a mess. This
is a case of a

printer simply doing the wrong thing, as the story has
been told.

You're certainly trashing this printer on a very
skimpy one-sided explanation of circumstances. While its clear that the
printer at least acquiesced to accepting the RGB, its not really clear that
he "agreed" to, and its not clear what the full communication
between Alain and the printer entailed.

It seems to me the printer most likely went out of his
way to rush this job through to completion after Alain's hardware problems
saw the job become a rush, and that's commendable.

You can make assumptions about the printer, but you
don't know how he promotes himself, or just what level of professional he
considers himself to be, he may not normally do any real pre-press at all.

Not knowing RGB workflow, and perhaps never having
sent an rgb file to his rip before, doesn't mean he's an inept printer, if
the first is true you probably wouldn't be working with him, if the latter
is also true you might also be able to start forming a picture of his
niche, but that's as far as you can go.

I still hear Alain desperate to get his job completed,
expressing concern for the .psd format, and more than likely somehwere
saying that the rgb will be fine, he does it all the time. The printer saw
no problems when he converted the .psd to a tiff, so didn't see need for a
call to Alain. Since it was a rush, Alain seemed unconcerned with the color
conversion and didn't request a proof, the printer didn't pull a color
proof either. Even if he thought the color was bad when he was on press, he
had notihng to base it on, and for all he knew Alain may have been quite
satisfied with crap. Telling someone in effect that their color or color
sense stinks isn't going to promote your relationship much either.

Maybe he should have pulled a proof anyway, and
thought of some diplomatic way of bringing the proof to Alain's attenion
without directly impugning the color, but that doesn't open him to the
degree of derision he's been receiving. And, if he had done that, Alain saw
no problem with the proof, and he wound up missing Alain's time needs,
where would that leave them both? If time seemed Alain's primary concern,
as I'd infer it would have, the printer probably picked the odds-on right
poison.

I do have to say though that your comment that the
customer obviously didn't know cmyk or wouldn't have sent a rgb file in the
first place seems to make Dan's argument more succinctly than he's made it
himself. And if the customer doesn't know cmyk, how exactly will profile to
profile conversions ensure that you'll meet that customers expectations?

documents between strangers has been a dead issue for
at least three years. The argument might have been made in 1998 and
1999 but the market has long since made its decision.

Dan,

I shouldn't give away my trade secrets, but color
management has become the single most important edge (and secret weapon)
that my shop has against our competition. Just today we landed an account
many states away from us because we were able to accurately print digital
photos using only the photographer's embedded profiles as a guide. We got
it right the first time, too. Soft proof to the monitor, then print finals.
Moreover, the job was hyper critical matching of leathers and fabrics.

The shop we took the account from was local to the
photographer and our mutual client, but they were a closed loop shop and
knew nothing about color management.

Please go right on believing that it's a dead issue,
but the fact that we're able to do a great job from over 1,000 miles away
and without a proof should tell everyone something.

When we recieve jobs that have supplied Hi res we
usually have to open them in photoshop to check size and whatever.So with
using embedded profiles this we can convert to our workspace will save
atleast one round or two of proofs.

For supplied CMYK we use thier profile to
convert and if there isnt one we assign one that makes the file look good,
visually. Then convert to our workspace.

Same goes for RGB files, if its got one we use it and
if it doesnt we assign one.

With out Color management this would require rounds of
Color correction and proofs.

So whats the big deal, Embedd the profiles when you
send out your files.

There are alot more printers using CM than Dan thinks,
and alot more using it right !!!

What your personal workflow choices have to do with
the subject of the

present thread I don't know. If you're saying that you
automatically honor all

embedded profiles and execute conversions based on
them without the client's

knowledge, and then you eat the cost of the job if
they don't like the result,

that would be relevant.

Well let me make it clear to you. My *personal*
workflow choices are entirely relevant to this thread because they stop
situations arising that cause people to post tales of woe like the one in
this thread.

And don't try and put up straw men.

I do not: "automatically honor all embedded
profiles and execute conversions based on them without the client's
knowledge"

Our workflow is *transparent* so that everybody is
aware of what we are doing and why. If a client sends untagged RGB to us
then they get a call to discuss their Photoshop settings, image history and
an email with a concise guide to Idea Colour Management.

Likewise, if they send tagged RGB that differs
significantly from their supplied proofs they'll also get a call asking why
and letting them know that we charge to fix this kind of problem. We'll
also offer to profile their desktop ink jet and supply simulation profiles
and techniques so that they can save time, money and heartache.

Chatting with people on the phone and sending a
pre-prepared email takes no more than a few minutes of our time, impresses
the hell out of the client and builds a good relationship.

If the printer that you are supporting with your
argument did the same as us then then thread wouldn't exist would it?

An interesting speculation that has nothing to do with
the thread. Whether

people are educated, or what equipment they own, or
how strict their process

control is, all have zero relation to the question of
whether to respectembedded

profiles from strangers. Service providers nearly
unanimously have decided

not to do so. One has to assume that at least *some*
of them are well

educated, own calibration devices, and have reasonable
QC procedures.

To the contrary. If the printer in question could
answer yes to all 3 points (especially point 3) then I doubt we'd have a
thread.

To what end? "Color management" is
irrelevant to this thread. All printers

manage color. The question pertinent to this thread is:
do you recommend

making automatic conversions based on embedded
profiles in files supplied by total

strangers? And if you do, do you recommend eating the
entire cost of the print

run if it turns out that this was the wrong thing to
do?

What a load of bollocks.

Colour management is entirely relevant to the thread.
You were whining on about Adobe1998 and the evils of profiles before I came
into the discussion.

And your term "automatic conversions" is
another straw man. We don't *automatically* convert anything and we won't
deal with data from total strangers (unless they agree to pay us additional
fees to fix it up) - you can't get away with it in RGB like you can in
CMYK.

The argument might have been made in 1998 and 1999 but
the market has long since made its decision. Trying to hide this by saying
that "ICC color management" has been widely adopted is to indulge
in the Andrew Rodney school of extrapolation. It's as if we were to ask the
printers at DRUPA whether they admired President Bush's decision to abstain
from alcohol, in view of his past problems with it; and if they all
answered yes, to come back and say that they unanimously supported every
one of his actions in Iraq.

Rubbish and more straw...

A printer may decide that profiles are a complete
waste of time. The fact that they own the final device in the chain and
will only accept CMYK data allows them to reach and maintain this decision
without a problem.

Many UK printers and publications choose this option
and stipulate that images, PDFs whatever will be rejected if they are not
CMYK and/or contain any of that pesky embedded profile data.

However, if a printer chooses to ignore profiles AND
accept RGB data then the results are more interesting and the screw ups
frequent - as was (probably) the case in this thread.

And there's no need for extrapolation when it comes to
discussing the adoption of colour management. 100 per cent of Photoshop
users have been forced to adopt "ICC Color Management" whether
they like it or not. What's the alternative, editing pixel values from a
CLI? Now that's what I'd call *working with the numbers*.

We choose to work it to mutual advantage. It doesn't
appear that the supplier in this thread did.

Responsible printers try to work with the limitations
of their clients.

Responsible clients try to work with the limitations
of their printers. There

is no need for this continual debate. The question is
not how printer *should*

operate but how they *do* operate. Those who are
interested in having their

jobs screwed up, and having adversarial relations with
their printers, do things

like surround their images with large black solid
areas, or bust small

three-color type out of a contrasting background, or
stay away from GCR in

areas where maintaining neutrality is important, or
rely on printers to interpret embedded

profiles correctly.

Those who are more interested in getting quality work
done in a reasonable

timeframe without undue aggravation avoid these
practices.

Sound advice - perhaps you should re-read the first
sentence and then tell me whether the printer was *responsible*?

I've got a sack of excellent quality spanners in my
garage. If I set up business as a mechanic and service your car will you
work with my limitations?

For supplied CMYK we use thier profile to
convert and if there isnt one we

assign one that makes the file look good, visually.
Then convert to our

workspace.

I was doing a good job of staying out of this thread,
until John wrote the above. <g>

John, this may have come up before between us (I seem
to recall a similar post in the past, but not the author) - but have you
ever considered the possibility that the supplied separation is what _is_
wanted, and that changing the numbers in the file may not be what the
supplier wanted? Has a customer ever wondered why their custom black
linework plate data is now spread over all four channels and is out of
register and fuzzy looking? Do they wonder why they now have black in a
certain colour where none was in their original separation?

This is the flipside to the tagged RGB issue. The
standard RGB workflow (does such an animal exist?) is to require a
description of the files numbers to be kept with the file. In this case
both the numbers in the file and the correct profile are needed for
accurate use down the production line.

CMYK is a little different, due to it being a final
output space for a specific condition. When handing off a _final_ file for
output - it might be my task to meet the printers specifications and I may
have a special game plan with how I craft a sep. Profiles are being used,
but the final file being handed off may not end up with a tagged profile if
this is a final layout file. Only the files numbers matter now, they simply
get passed on unaltered to the RIP for plotting.

Any digital proofing can simply presume the final
output aimpoint CMYK as the definition of my files numbers - the profile is
not needed for film or plate imaging in the standard prepress workflow.

Mystery meat CMYK does serve a purpose here, as the
file is in output space for this particular setting, the tag does not add
extra benefit (the tag or aimpoint is presumed and known by all parties in
the loop).

I would not want someone to convert my final CMYK
crafted sep based on my tag to thier house profile (which was my aimpoint
anyway) - and in the process re-separate my tweaks to the K and other
plates. Yes the tag would describe the file, but the SP knows what this
description is anyway! By not having a profile, it can be less tempting to
change the files numbers. With the profile, it can happen with more ease -
but with no profile the conversion source has to be presumed or manually
assigned...which is not something that _most_ prepress and printers do, as
they traditionally treat a CMYK sep final data and not something to be
changed without explicit approval.

In my little world, CMYK is considered final and hands
off unless otherwise noted. Unlike RGB, it is final and output ready and
not open to further interpretation - the numbers in the file are that way
for a good reason.

So we have had a long thread chewing over old ground
once more, on the same old RGB workflow issues, which has sidetracked the
original issue somewhat, in that RGB would not normally be supplied for
this work, but due to unforeseen issues RGB was supplied. I hope I never
have to start a thread of my own which laments that I handed off a hand
crafted separation which I did not want altered, which was then mangled
through an unwanted conversion. I can see just as many issues with this
type of workflow as with the RGB tag being ignored.

So whats the big deal, Embedd the profiles when you
send out your files.

See above - I do not want you [anyone, nothing
pesonal] messing with my CMYK values!!!

I find what the next party requires, and supply that.

If the numbers in my file do not suit the conditions -
then, why was I given an unsuitable aimpoint to separate to?

The service provider does not need a profile in the
fianal CMYK image - as the SP knows what profile describes the setting that
will produce the output - which is what I am working towards as my aimpoint
- which was given out as part of the 'material specifications' that I am
working toward.

We all need to get on the same bus, communication is
key

Agreed, communication is the key - all we need is an
_agreed_ method of communication between both parties.

John, the bus you drive and the one I drive are very
different - I don't think I even want a test drive [bus being chosen way to
handle incoming data].

Chatting with people on the phone and sending a
pre-prepared email takes no

more than a few minutes of our time, impresses the
hell out of the client

and builds a good relationship.

Amen to that. That1s what service means. It1s pretty
clear the printer that hosed the job discussed in this post isn1t getting
much repeat business from the poster.

If the printer that you are supporting with your
argument did the same as us

then then thread wouldn't exist would it?

Exactly. But god forbid a profile or CMS workflow
actually work or insure color communications. That would mean someone is a
3calibrationist2 which is worse in some people1s minds than being
un-American!

Colour management is entirely relevant to the thread.
You were whining on

about Adobe1998 and the evils of profiles before I
came into the discussion.

I1m not sure how long you1ve been on this list but
this has been preached for so many years and is so bogus it1s getting
tiring. If Dan keeps saying such things, with no backup of any kind of
stat1s other than his partially exposed ear to the ground, eventually
someone other than Dan will believe it.

A printer may decide that profiles are a complete
waste of time. The fact

that they own the final device in the chain and will
only accept CMYK data

allows them to reach and maintain this decision
without a problem.

However, if a printer chooses to ignore profiles AND
accept RGB data then

the results are more interesting and the screw ups
frequent - as was

(probably) the case in this thread.

Exactly. IF said printer can1t deal with RGB to CMYK
conversions, simply don1t except RGB. Watch business go down the tubes but
that1s not a color management or technical issue at all. Printer in
question was out of his league, didn1t proof and didn1t know how to make a
conversion. As soon as they opened the file a big flag needed to come up
saying 3Game over2.

It1s funny how this list lumps along a few posts a
month until some color profile issue is discussed and then it really gets
going. Only to have a few dinosaurs claim that profiles are the evil of the
world or that no one for years has accepted that profiles are useful for
anything other than hosing a job. All kinds of self proclaimed statements
like profiles haven1t been on printers radar or that 3the industry2 has
accepted this or that. It1s nonsense. It1s nice to see for a change others
that are calling this straw man as you call it, exactly what it is. Then
silences for a few days so the challenges go unnoticed and back to a limp
for a few weeks.

I am curious about something here. If accepting files
in an RGB space, such

as Adobe RGB, with the profile embedded is so far
below the radar for

printers why is there a very pronounced trend on the
part of the magazine publishers

to PREFER Adobe RGB?

It's certainly true that the industry has been
scrambling since 1998 to try to get back to a point where RGB files carried
their own meaning and weren't susceptible to disastrous misinterpretation.
The link Dennis provides compensates by demanding that incoming files be in
Adobe RGB.

That, in itself, is a strong vindication of everything
I've been saying over the past half decade. As Andrew Rodney and
others were so fond of saying in 1998, the beauty--nay, the genius--of the
ICC revolution is that such fiats are no longer necessary. Every user can
have his own version of RGB, for they will all carry their own unambiguous
profile. Let a thousand RGBs bloom!

In this paradise, the magazine publisher has no reason
to ask us to use Adobe RGB as opposed to TomRGB, DickRGB, or HarryRGB.
They're all treated the same, with an unambiguous, colorimetrically correct
conversion to whatever the unambiguous, colorimetrically correct output
space is.

Back on this planet, such every-man-for-himself
workflows have been a resounding flop. So, just about every exchange of RGB
files now has to be negotiated. It's a shame that it's necessary just to
get us back to where we were pre-1998, but it is, and that's what Dennis's
group is doing, to its credit.

So, instead of giving us the open-format paradise that
Andrew and his friends promised us, they *dictate* the input, saying,
"We do not accept sRGB or CMYK, leave all color management to the
prepress professional since they do this job best." IOW, they are as
hostile to embedded profiles, in a different way, as Alain's printer. Their
refusal to accept files with different embedded profiles is about as clear
an indication of the complete failure of this the-profile-speaks-for-itself
workflow as one could ask for.

But, of course, all this has nothing to do with the
thread. Handing off an Adobe RGB file to somebody who has specifically told
us that Adobe RGB is what they want is one thing, and if anything goes
wrong, we can certainly blame Dennis's group. Handing off an Adobe RGB file
to somebody who hasn't indicated they know what it is, is quite another. In
that case, the chances are the job will get hosed.

Every one of Dan's comments about printers respecting
embedded profiles has included the word "strangers". If the
printer and the client talk, and develop some mutual respect regarding
their respective use of color management techniques, and decide to give
embedded profiles a try, and run some tests, and check the results, and
decided that all is OK, then they aren't strangers any more.

When I ran a service bureau we couldn't even trust a
"stranger's" fonts. How on earth are we going to trust
software as complicated and critical as color profiles, when it comes from
sources we haven't verified?

It's certainly true that the industry has been
scrambling since 1998 to try

to get back to a point where RGB files carried their
own meaning and weren't

susceptible to disastrous misinterpretation.

The industry? Or Dan? Again, I ask that you provide
some kind of data to back up such a claim.

That, in itself, is a strong vindication of everything
I've been saying over

the past half decade. As Andrew Rodney and
others were so fond of saying in

1998, the beauty--nay, the genius--of the ICC
revolution is that such fiats are

no longer necessary. Every user can have his own
version of RGB, for they

will all carry their own unambiguous profile. Let a
thousand RGBs bloom!

First, there ARE a thousand RGB1s that could bloom
from every capture device on this planet. Getting that into a few sets of
well behaved RGB editing spaces is a brilliant idea of Adobe1s (and before
them, people like Radius for PressView users).

In this paradise, the magazine publisher has no reason
to ask us to use Adobe

RGB as opposed to TomRGB, DickRGB, or HarryRGB.
They're all treated the same,

with an unambiguous, colorimetrically correct
conversion to whatever the

unambiguous, colorimetrically correct output space is.

I can take TomRGB, DickRGB, or HarryRGB or for that
matter ANY tagged RGB

and get to Adobe RGB or where ever I want. I1m not
saying this is a great

idea but it1s certainly far better than unknown RGB
which is simply a set of

numbers with no meaning. I still haven1t understood
(nor have you ever

clearly or for that matter unclearly) explained why
there is any benefit to

mystery meat digital files.

Files can either have a meaning or not. They either
have a profile or they don1t. You can either read English or you can1t so
why would I send you a letter in German knowing you can1t possibly read it?

Back on this planet, such every-man-for-himself
workflows have been a

resounding flop.

Says who? Everyman has been scanning and capturing
data for at least a decade expect for that dinosaur model whereby user is
supposed to pay for some on the fly CMYK scan to size and do this every
time they wish to reproduce the file. That1s a flop Dan. I have the stat1s
to back it up too. Do you really think the number of images produced TODAY
from RGB producing digital cameras is less than what it was when you were
scanning transparencies on a scanner that is likely unable to sale today on
ebay?

So, just about every exchange of RGB files now has to
be negotiated.

It's a shame that it's necessary just to get us back
to where we were

pre-1998, but it is, and that's what Dennis's group is
doing, to its credit.

RGB has to make it to CMYK yes? Without any descriptor
of RGB how do we get there correctly with visual back up? And what does
3Negotiated2 mean? Pre 1998, everyone1s RGB was totally ambiguous and based
on an inherently unstable device (their display) which a fraction of users
even calibrated (god forbid we calibrate a device or be known as
calibrationists. Let1s not even calibrate those Imagesetter1s or film
processors).

So, instead of giving us the open-format paradise that
Andrew and his friends

promised us, they *dictate* the input, saying,
"We do not accept sRGB or

CMYK, leave all color management to the prepress
professional since they do

this job best."

I don1t know who1s saying this but clearly they don1t
IF they haven1t a clue how profiles and Photoshop works. I1d far prefer
sRGB than mystery meat RGB. I1d rather have Adobe RGB than sRGB but I'll
take sRGB if indeed the file is in sRGB and tagged as such. And if it1s NOT
in sRGB, I'll see so OR I'll produce a visual match the file as tagged in
sRGB (what more can a customer ask for?).

My question would be, why make it mystery meat and
untagged it? Seems like this would make more people who have a clue about
profiles suspect the end user is of questionable skill. IF you1ve made a
screaming CMYK conversion for my process (you made a custom profile), the
only reason I1d NOT embed is if I thought you1d have a hissy fit and hose
my job. Again this all boils down to communications. I1d prefer that
someone take my CMYK file (in as you point out output space by nature), not
mess with it and simply print the job. IF they suspect something is up,
make a phone call. Or I as a custom could simply instruct the printer to
print the file and not touch it. Seems pretty easy to me. The question is
then, why not have the profile?

My question would be, why make it mystery meat and
untagged it? Seems like

this would make more people who have a clue about
profiles suspect the end

user is of questionable skill. IF you've made a
screaming CMYK conversion

for my process (you made a custom profile), the only
reason I'd NOT embed is

if I thought you'd have a hissy fit and hose my job.
Again this all boils

down to communications. I'd prefer that someone take
my CMYK file (in as you

point out output space by nature), not mess with it
and simply print the

job. IF they suspect something is up, make a phone
call. Or I as a custom

could simply instruct the printer to print the file
and not touch it. Seems

pretty easy to me. The question is then, why not have
the profile?

Andrew, it may end up in the hands of someone who
thinks it is a good thing to convert to their output space, based off my
profile (even though my aimpoint is the same as the one they are separating
to). You know who you are. <g>

As stated, all parties concerned know the separations
aimpoint. The output folk dictate it - and I meet it. Call me old
fashioned, but I still believe in working with the next step in mind,
rather than forcing my own way on others down the line (which will not
work).

To convert my final CMYK data would then either take a
conscious step via assign profile, or the source would be presumed as I
chose not to describe it.

True, by not describing the CMYK values, I have
probably hosed the unwanted conversion and colour will be very different
due to the presumed CMYK source being way off.

By tagging the CMYK profile, the unwanted
conversion would be a very close or same match for colour - but the actual
colour builds of the plates and the GCR ratio and special K plate tweaks
would be lost.

Either way an an unwanted conversion has taken place,
hosing my files wanted values.

In my experience, prepress and printers who receive
tagged CMYK shrug their shoulders and wonder why? Tagging the CMYK would
make many of these dinosaurs suspect that the originator did not know what
they were doing, the opposite of what you propose. Wether or not that is
for right/wrong/true/false is not the point - just some of the attitudes I
have seen. I have also seen those who understand ICC colour management for
the tool that it is and who have a knowledgeable and balanced view. I have
also seen the ignorant and the confused well meaning users with crazy
settings and methods.

Let me ask this question in return (not directed at
Andrew, unless he wants to have a shot at it), although Chris Murphy has
stated on this list one answer to this question in the past...

Why did the authors of Real World Colour Management
choose not to tag thier CMYK press ready files for their book? If anyone
was going to champion this effort, one would think it would have been them.
What better way to show those who see no need for a description which is
known to all parties to be tagged to the file, than to do it on the live
print production of the book devoted to real world use of colour
management.

Could it be in the real world, that real, real world
colour management practitioners see no need for tagging every image with
the same output description, for a output process which does not require
said description - and even if it is needed at some interim point
(proofing), that description is known by all parties in the production loop
anyway?

...except perhaps years of experience. In our
commercial photo lab, we've been printing color negatives for 30 years with
little basis for quantifying 'correct color' except experience viewing
printed images. Grossly bad color hits you in the face; An untrained eye
can usually spot it, a trained eye can define and correct it.

If we were to dismiss color we thought was 'bad'
because we lacked a reference, we'd have been out of business years ago.
Color professionals have a reference; it's called experience... the stuff
we used to rely on before digital came along.

That's not to say that this particular job was grossly
misprinted, for all we know the two parties are splitting hairs over
minutiae... some clients require valium over 2 points of cyan. But from the
sound of it, what came off the press should have raised an eyebrow,
regardless of the whole set of circumstances including turnaround,
profiles, RGB... etc.

You're certainly trashing this printer on a very
skimpy one-sided explanation of circumstances.

I totally agree. The initial question "Who's at
fault" cannot possible be answered without input from both parties and
a sample of the printed job (Alain, if you have a website, why not scan and
post?). The benefit of this entire thread is in uncovering and
understanding the dynamic between buyer and vendor when things go wrong.

"In this paradise, the magazine publisher has no
reason to ask us to use Adobe

RGB as opposed to TomRGB, DickRGB, or HarryRGB.
They're all treated the same,

with an unambiguous, colorimetrically correct
conversion to whatever the

unambiguous, colorimetrically correct output space
is."

I would like to add, that by calibrationist's
admission, there are a plethora of possible 4-color profile options to
consider. Possibly one for every substrate/inkset combination and
finishing option. Add to this profile "tweaking" to suit
the unknown and subjective tastes of print buyers who are all way too
behind schedule to be concerned with all of the niceties of print paradise.

On the other hand, there may be nothing but a lack of
will, to stop print customers from contracting the services of color
management consultants and obtaining a profile made for a particular
ink/stock combination, and tweaked according to their taste. Then
miscommunications about color expectations can be discussed between them.
Meanwhile, the print shop comes up to density and prints more jobs.

A custom or more commonly, an Adobe v2 profile used as
a 'standard' aimpoint is the base level to getting a screaming CMYK
conversion.

It is what one does post separation that counts -
using all those wonderful tools and methods available in Photoshop (which
is what I would prefer this list concentrate on rather than finger
pointing).

My question would be, why make it mystery meat and
untagged it? Seems like

this would make more people who have a clue about
profiles suspect the end

user is of questionable skill.

Because if it's tagged its far more likely that
someone will make an unintended conversion. For example, I may have
done a separation with a custom black build that will print beautifully on
SWOP. I may send that file out with a profile for my particular
separation parameters to a shop that prints SWOP and could print my file as
is just fine. However if they have some house profile that describes
SWOP with a different type of black generation and they happen to convert
my file from my SWOP to their SWOP, they've just hosed my custom separation
and altered the intended look of my file.

With CMYK its possible to have any number of profiles
using different recipes for building the separation that all describe the
same press characteristics. The choice of which one to use is based
on image content, not press characteristics. If an unintended
conversion takes place between those profiles, the carefully crafted custom
seps are hosed. The image will likely still print reasonably well,
not horribly, but not like the person who created the seps intended.

I used to send out everything tagged figuring what
harm could it possibly do. Then I got burned a couple of times in exactly
the situation described above.

I'm right with you on your arguments for embedded
profiles in RGB files where conversions down the line are inevitable and
wanted. I want that tag there so any conversion will be made
properly. But if I'm sending out CMYK files, ready to print,
including a profile just adds to the probability that someone will act on
it improperly. A CMYK file with no profile will generally be left
alone.

I wish I could but unfortunately the material is
copyrighted and I cannot reproduce in any way, shape or form... sorry! This
is not BS, I would quite simply lose my job.

The colour was MILES off! The reprint is acceptable.
We paid half the cost of the job again. I think this is fair since it was a
communication error (amongst other things) and it is/was both of our jobs
to communicate effectively.

BTW, the printer had PS set up to ignore profiles
completely and didn't get a warning when he opened the file. I have looked
at the colour settings in his PS, he didnt seem aware of the fact that
these settings existed. He did say that he normally uses PDF to exchange
files and they do not normally EVER use proofs to preview a job for the
client.

entirely relevant to this thread because they stop
situations arising that

cause people to post tales of woe like the one in this
thread.

Your personal workflow choices will answer,
among other things, the following:

1) Can you be relied on to process a QXP/6 file
from a PC?

2) How about an InDesign 2 file containing
transparency, any platform?

3) How about a file that requires you to make
an accurate conversion based on an embedded RGB profile?

4) How about a file that contains lots of
instances of a particular Multiple Master font?

5) How about a file prepared in CorelDraw 8
with lots of nested gradients containing fonts (provided) from an unknown
foundry?

6) What about if any one of these jobs comes in
on an 88mb Syquest disk?

We know, because you've told us, that you definitely
can deal with #3. Maybe you can deal with all five of the others as well.
But suppose we have such a job, in one of the other five categories, that's
due tomorrow morning.

Anyone sending such a job to you without first
inquiring about your fitness to handle it, needs a checkup from the neckup.

All six of these items are nonstandard services--most
service providers are going to answer yes to some of them, but for any one
of the six, well over 50% will answer no. People who simply assume that a
provider is going to be able to cope with any particular one of them are
asking for the result Alain got.

You've made your choice about which services to
support and how seriously, and I hope the choice works well for you.
However, different firms make different decisions, ordinarily based on what
their clients need. The printers I speak to here are becoming seriously
concerned about their ability to handle InDesign files because they are
seeing increased demand from clients, therefore they are diverting
resources to train personnel to be able to handle the problem. They see
zero client demand to deal with any profile-related issue, therefore they
are disinclined to learn anything about it.

If the printer that you are supporting with your
argument did the same as us

then then thread wouldn't exist would it?

Of course not. It would be put off for another three
months until the next person who doesn't know that printers and profiles
don't mix runs into a similar problem and writes to tell us about it.

What a load of bollocks. Colour management is entirely
relevant to the

thread. You were whining on about Adobe1998 and the
evils of profiles before I

came into the discussion.

You are apparently mistaking someone else's posts for
mine. As anyone familiar with my writings will tell you, and as the
archived posts will confirm, I have nothing against Adobe RGB, and
recommend it in certain settings in my book. However, I do issue the strong
warning that Adobe RGB is unique among the four majors in that if it is
misinterpreted the result is likely to be really, really bad. And I say,
even in the latest edition of my book, "For work primarily aimed at
non-Web RGB: If you are certain that your workflow won't let anyone convert
(or fail to convert) it improperly later, use Adobe RGB. If not, use
ColorMatch RGB."

As for the evils-of-profiles drivel, I have always
advocated that service providers take account of incoming profiles and make
intelligent decisions of whether to use them or not. Thus, if the job had
come to a company I was running, it wouldn't have been screwed up, either.

But, as we all know, service providers have by and
large not taken that advice.

Again: this thread has nothing to do with color
management. It has to do with common sense. Forget the way the world
*ought* to work. Concentrate on the way the world *does* work.

In the archives of this list, the ColorSync list, in
my book, and in various other publications, you will see warning after
warning after warning that giving a job that depends on correct
interpretation of a profile to an unknown service provider is a recipe for
disaster. It's gotten to such a point that even Andrew Rodney, as
CMYK-phobic a person as there is on this planet, advocates converting files
to CMYK rather than depending upon an unknown service provider to do it.
Me, I always give either untagged CMYK or LAB and recommend that others do
so as well.

But some seem to feel as a matter of principle that
they must court disaster. They declare, on principle, that it is absolutely
the service provider's obligation to know what to do with a tagged file,
and that there is no need to take such an easy insurance policy against his
not knowing. Thus, the parade of principled people with ruined jobs
complaining to this and other lists.

I've said enough on this topic now, so before leaving
the thread, I offer the following to those who insist that strangers
convert their files properly:

This is why repurposing CMYK content needs a
DeviceLink profile (a class of ICC profile) instead of two Output Device
profiles. Black only can be retained, or even scaled (compensating for dot
gain between the two black channels), preserve channel purity, etc.

Profiles are being used,

but the final file being handed off may not end up
with a tagged

profile if this is a final layout file. Only the files
numbers matter

now, they simply get passed on unaltered to the RIP
for plotting.

Not quite. BOTH the file numbers and color appearance
matter.

See above - I do not want you [anyone, nothing
pesonal] messing with

my CMYK values!!!

If the job wasn't separated for the specific print
condition, yes you do. You just don't want certain aspects of the data
changed, such as black only drop shadows, or text made out of 100% yellow,
or 80% black. But if it's necessary to print 65% black to get the same
*appearance* you had at your value, what do you care so long as it's still
black only? You'd most likely prefer the result of the scaled black.

If the numbers in my file do not suit the conditions -
then, why was

I given an unsuitable aimpoint to separate to?

If you're using their profile, and it gets embedded,
there will be no repurposing.

The service provider does not need a profile in the
fianal CMYK

image - as the SP knows what profile describes the
setting that will

produce the output - which is what I am working
towards as my

aimpoint - which was given out as part of the
'material

specifications' that I am working toward.

If the job order stipulates that you are responsible
for having converted everything to a specified profile, provided from the
printer - that may be an adequate substitute for some printers. For others,

they'll want to see it embedded. What do you care
whether it's embedded or not, so long as you know they're going to treat it
correctly?

Please try not to exaggerate my position. For all
practical purposes, it's a hypothetical situation because we don't have
both sides of the story, and we don't necessarily have the full story from
even one side. But as it was presented, which the discussion has already
been qualified as being in the context of, and as I also reiterated
"as the story has been told", criticism of the actions of this
hypothetical printer is not without merit. There are all kinds of questions
I have about the actual event, but that information simply isn't available.
And it is absolutely possible the printer handled this logically in all
other faucets, except where it comes to insisting on a proof.

While its clear that the printer at least acquiesced
to accepting

the RGB, its not really clear that he
"agreed" to, and its not clear what the

full communication between Alain and the printer
entailed.

His agreement is implicit by not having rejected the
job prior to printing it.

Not knowing RGB workflow, and perhaps never having
sent an rgb file to his rip

before, doesn't mean he's an inept printer,

Having never done so, and subsequently going to press
without a proof on top of it does demonstrate a certain lack of
understanding of the potential consequences.

I still hear Alain desperate to get his job completed,
expressing concern for

the .psd format, and more than likely somehwere saying
that the rgb will be

fine, he does it all the time. The printer saw no
problems when he converted the

.psd to a tiff, so didn't see need for a call to
Alain.

Why would there be a problem converting PSD to TIFF?
The concern should be with RGB to CMYK, not PSD to TIFF.

Since it was a rush,

Alain seemed unconcerned with the color conversion and
didn't request a proof,

the printer didn't pull a color proof either. Even if
he thought the color was

bad when he was on press, he had notihng to base it
on, and for all he knew

Alain may have been quite satisfied with crap. Telling
someone in effect that

their color or color sense stinks isn't going to
promote your relationship much

either.

Maybe that happened, but the logic fails in numerous
places because the printer is making all kinds of assumptions in your story
that are known to cause problems between printer and customer.

Maybe he should have pulled a proof anyway, and
thought of some diplomatic way

of bringing the proof to Alain's attenion without
directly impugning the color,

but that doesn't open him to the degree of derision
he's been receiving.

If he *really* sent an RGB file to a PostScript RIP,
which subsequently used a generic source and generic destination profile,
he really does, but hopefully he learns from the mistake. And it is a
mistake, not proofing the job, and then insisting the customer pay for the
press run only makes it a bigger one.

I agree that device links are good when it comes to
managing plate ready files.

You also need an application that can use Device links
and one to create a good one that doesnt reseparate through lab.

But for loose color that the client wants to see
proofs on that are supplied from god knows where I prefer to manage them in
Photoshop. If I get a sep that was prepared for 20% dot gain it would be
flat and washed out, if i have a profile to convert to our specs it
gets the right numbers for our press conditions.

Our gain is much less even on our web presses.

Steven you know better than to think you know how
every printer is going to print.

Every place is different and everyone has a different
flavor of swop, different ink sets and so on. So letting a printer convert
your file would be a good thing, my opinion.

Our customers like the way we are handling the files
and cant believe the difference form where they did the job the last time.

We have seen so many times if a job goes through not
colormanaged the proofs get marked up so bad thet you end up starting over
by assigning a profile and converting to our workspace and it gets you 90%
if not 100% there.

Color management can be good for everyone, you just
cant ignore it and pretend it doesnt work, like dan would like you to
believe.

to have a shot at it), although Chris Murphy has
stated on this list one

answer to this question in the past... Why did the
authors of Real World

Colour Management choose not to tag their

CMYK press ready files for their book?

From what I know from Bruce, the number of images and
the size of each profile, the resulting storage of the book would have been
much larger.

I this situation, I have no problem NOT embedding a
profile. In fact, if I KNOW a printer is simply going to send the numbers
in my file to their output device without messing with it, there1s no
reason to embed a profile what so ever. I1m not against this one bit. The
file is in the correct output space and the profile (descriptor of the
data) doesn1t serve any purposes. My question would be in a case where you
do NOT know if the printer will honor the numbers, is there a reason not to
embed the profile? I can1t think of one off hand other than saving 500K to
1mb per file. That1s viable but dangerous if you suspect the printer might
try to open and worse convert the data.

In the case of the book, there was no question that
the authors had control over the process whereby they knew the numbers were
correct for print and going to that output device with no other alterations
of the data. No descriptor was needed because the only people who would
open, view, correct or convert the data knew the right answer (what the
profile should be) and they knew those numbers were not going to altered.

Could it be in the real world, that real, real world
colour management

practitioners see no need for tagging every image with
the same output

description, for a output process which does not
require said description -

and even if it is needed at some interim point
(proofing), that description

is known by all parties in the production loop anyway?

Yes. The profile as we know is only a label. So it
serves no purpose in this situation. In fact, if I were 3king of the world2
and mandated that every printer would simply send all the numbers in a file
to the output device it was intended for, we would not need to embed a
profile. However, some printers feel they need to view the file or do some
kind of conversion to the existing numbers. In such a case, unless provided
with a profile, they simply can1t do this without guessing. Why guess?

One could embed one profile in one file (say a
representative image among hundred of others) and leave the others untagged
for space and at least the person on the receiving end could open the file,
view it, extract the profile if necessary and use it for the other files.
But again, if the numbers are simply going to the device with no other
human intervention, the profile serves no use in this case.

Only by a shop that doesn't know what it's doing. I'd
like to hear anyone demonstrate how unintended conversions occur otherwise.
How is it more likely, let alone far more likely, that a shop will convert
ONLY BECAUSE there is an embedded profile? Why isn't it just as likely that
an untagged image will have a source profile assumed, and then converted to
some other destination?

I do see a problem with *intended but undesired*
conversions due to embedded profiles - that's a discussion about automation
that isn't well suited to this forum.

However if they have some house profile that describes
SWOP with a

different type of black generation and they happen to
convert my file

from my SWOP to their SWOP, they've just hosed my
custom separation and

altered the intended look of my file.

How, specifically, would this occur *unintentionally*,
and do you have any data to show how often this happens? I have heard only
3rd hand stories as though they were legend, and most of them were from Dan
Margulis, yet he hasn't ever described how this happens or shown data with
a sufficient sample size to support the contention.

If an unintended conversion takes

place between those profiles, the carefully crafted
custom seps are

hosed.

Not with DeviceLinks, that's the point of using them
and why their use is on the increase.

I used to send out everything tagged figuring what
harm could it

possibly do. Then I got burned a couple of times in
exactly the

situation described above.

And you called them on this, and they acknowledged
there was an unintended conversion of your file, and acknowledged
responsibility? What else happened?

I'm right with you on your arguments for embedded
profiles in RGB files

where conversions down the line are inevitable and
wanted. I want that

tag there so any conversion will be made properly.
But if I'm sending

out CMYK files, ready to print, including a profile
just adds to the

probability that someone will act on it improperly.
A CMYK file with

no profile will generally be left alone.

I disagree. It's just as possible something will be
assumed as source, as someone erroneously using your profile as unintended
permission to convert your file.

Summary: It's logical to not embed a profile in a CMYK
image, if you assume that whoever you send it to won't know what they're
doing when it comes to color management, and has improper settings that
would lead them to make an unintended conversion of your document only
because it has a profile embedded in it.

If you look at the members, it's pretty easy to see
why they might do this. They are very likely looking to engage in a
streamlined, normalized, single assumed profile workflow. It's probably so
they can automate separations.

You're taking one example, and blowing it out of
proportion as though it's representative of a larger market. You cannot
prove this.

Their refusal to accept files with different embedded

profiles is about as clear an indication of the
complete failure of

this the-profile-speaks-for-itself workflow as one
could ask for.

Under "What is DISC?" they say: "We are
recommending the Adobe RGB 1998 color space because it is large enough to
encompass most digital capture, display, and output devices." There it
says recommended, elsewhere it sounds like a requirement. I'll see if one
of their contacts can clear up the apparent contradiction, and why they
would require a particular space rather than merely highly recommending a
certain space. (It's probably for ease of workflow, to avoid questions, to
avoid having to train potentially tons of people, to avoid getting
potentially marginal or jacked up source profiles, on and on...)

But, Dan, you love to make assumptions. You're
selectively skeptical, Dan. The refusal to accept files other than Adobe
RGB files *including CMYK* is a mostly clear indication of an intent to
automate some aspect of workflow regarding *specifically* digital images.
Their documentation even makes it more specific that they are referring to
digital camera images vs. stock photography which is also digital.

When you call a printer and ask for their specs
wouldnt it be easier if they just gave you their profile ? Maybe Im too
optomistic here but there are more printers using profiles than not atleast
in high end printing. Like someone said ealier that CM works and helps to
save money so I would figure that all of the Major printers are into it in
the US anyway not sure overseas yet.

Sure you can color correct and image with out using a
profile to profile conversion and do a good job but somewhere you need to
see proofs, one to see where you started and one to see where you
are.Proofs arent cheep right? Just that alone with the time it takes to
make one is enough to get you thinking about it anyway.

m trying to get Gretags IQ140 so we can start
managing plate ready files, it has helped so much we want to take
everything into a Color managed workflow.

Why did the authors of Real World Colour Management
choose not to tag their

CMYK press ready files for their book?

It had to do with size of profiles magnified by the
number of images, not due to some neurotic concern that the printer was
going to convert all of our files because a profile was embedded in them.
Plus the specific destination (press, ink, paper, etc.) was known and was
profiled. Since that was the only possible destination, and because the
submission of final press ready material was our responsibility per the
contract, it simply was not necessary.

Embedded profiles are not a universal requirement of
color management in all situations. They are an aspect of it, and a tool in
the arsenal.

to cope with any particular one of them are asking for
the result Alain got.

He didn't assume! He told the printer it was RGB from
the get go and the printer accepted the job. The assumption as on the part
of the printer who took the job. Assuming it would be OK, or assuming Alain
would accept color miles off the mark.

They see zero client demand to deal with any
profile-related issue,

therefore they are disinclined to learn anything about
it.

They probably don't know the first thing about it, and
if they do ask presumably the printer tells them its all about the proof
and if there are any problems, that's when everyone finds out and then gets
them fixed. Customers are used to these kinds of iterative
proof-fix-proof-fix workflows and don't know any better to be able to say
anything about an alternative let alone complain about it. It's

merely part of a traditional workflow.

You are apparently mistaking someone else's posts for
mine. As anyone

familiar with my writings will tell you, and as the
archived posts will confirm, I

have nothing against Adobe RGB, and recommend it in
certain settings

in my book.

Dan, you are the Iraqi Information Minister!!!! You
wrote, barely two days ago:

"The culprit is invariably Adobe RGB. I don't
favor that RGB definition anyway, but that's beside the point."

So you have nothing against Adobe RGB, but you don't
favor it, and it's invariably the culprit? Tell me, will our stomachs roast
in hell at the hands of Adobe RGB, or just embedded profiles in RGB images?

Again: this thread has nothing to do with color
management. It has

to do with common sense. Forget the way the world
*ought* to work. Concentrate

on the way the world *does* work.

Of course we should. And then nothing ever changes.
Nothing ever gets better. People can have the same old arguments, and you
can pull your responses from archive. They can do the age old, it works
perfectly well workflow of iterative fix and proof instead of improving
workflow efficiency. You don't have to update your book as often, and you
can keep on telling people the same things year after year, status quo, day
in day out, on and on.

Why did the authors of Real World Colour Management
choose not to tag their

CMYK press ready files for their book? If anyone was
going to champion this

effort, one would think it would have been them. What
better way to show

those who see no need for a description which is known
to all parties to be

tagged to the file, than to do it on the live print
production of the book

devoted to real world use of colour management.

Perhaps they used a printer that told them that images
with profiles would be rejected because they have no interest in colour
management?

As has already been pointed out - the owner of the
final device in the chain has this option open to them without it affecting
the image quality in any way whatsoever.

They don't need to make any conversion. They just need
to ensure that correct percentage of cyan, magenta, yellow and black
appears consistently on every page.

They don't need tags on the images to create proofs
either. The proofer is adapted to match the response of the press - the
image data does not need to be converted.

The main beneficiaries of colour management are the
originators of the images and the intermediaries who have to work on them,
repurpose them and then pass them on to who-knows-where. In other words
*everybody apart from the owners of the printing press.

In Dan's *real world* the printers could sit about
demanding CMYK data only and bitching about colour management zealots all
day without any repercussions.

The problem is that they need to get work to pay for
the sales reps Mercedes and are drawn like flies to a turd to the source of
some major image problems: PHOTOGRAPHERS and DESIGNERS.

You know the result when two tectonic plates meet? The
creatives don't know the difference between UCR and HRT (yeah, that's
hormone replacement therapy). The producers don't know ICC from MCC
(Marylebone Cricket Club).

The really funny thing about the situation is that
they don't need to do much more than RTFM that came with Photoshop, agree
to take responsibility for profiling and maintaining their own equipment
and then sit about discussing what makes a good image.

Instead they argue with each other and post their
sorry tales to this and many other forums.

Still, I shouldn't grumble. It's good business being
an intermediary between the warring factions :-)

On 7/2/03 at 11:59 AM -0400, Dan Margulis wrote in a
message entitled "Re: [colortheory] Re: Who's at fault?":

However, I do issue the strong warning that Adobe RGB
is unique among the four majors in that if it is misinterpreted the result
is likely to be really, really bad. And I say, even in the latest edition
of my book, "For work primarily aimed at non-Web RGB: If you are
certain that your workflow won't let anyone convert (or fail to convert) it
improperly later, use Adobe RGB. If not, use ColorMatch RGB."

But what then, if the client sends the printer an
untagged RGB file that was created in a ColorMatch RGB working space? If it
is opened under the assumption that it's untagged Adobe RGB, the result
before CMYK conversion will be too dark and too strongly red.

With the converse instance -- an untagged RGB file in
was created in an Adobe RGB working space that is opened under the
assumption that it's untagged ColorMatch RGB -- you'll have the result you
disparaged in the last Makeready article: an overly light file that's weak
in saturation.

While neither is preferable, a case could be made that
problem #1 (too dark and red-cast) is more damaging that problem #2 (too
light and unsaturated).

This just seems to further demonstrate why not
embedding a profile in an RGB file is a invitation for problems regardless
what defensive strategy you employ.

We know, because you've told us, that you definitely
can deal with #3. Maybe

you can deal with all five of the others as well. But
suppose we have such a

job, in one of the other five categories, that's due
tomorrow morning.

Anyone sending such a job to you without first
inquiring about your fitness

to handle it, needs a checkup from the neckup.

It may surprise you, but my colour managed workflow
also doesn't:

7) cure cancer,

8) remove unsightly nasal hair,

9) add a *genuine* 3 inches to the length of my penis

But the important thing is that I don't have you
bitching about my service because I didn't claim to be able solve any of
the problems that you have cited - or imply that I could by accepting the
job with the problems that you've warned me about.

But some seem to feel as a matter of principle that
they must court disaster.

They declare, on principle, that it is absolutely the
service provider's

obligation to know what to do with a tagged file, and
that there is no need to take such

an easy insurance policy against his not knowing.
Thus, the parade of

principled people with ruined jobs complaining to this
and other lists.

ICC profiling is the only insurance policy that I
have!

We scan and send out RGB data, we retouch both RGB and
CMYK and proof both RGB and CMYK. You advocate a non-ICC insurance policy
because you have one open to you. We don't and neither do the photographers
who are creating most of the images that we work on.

I've said enough on this topic now, so before leaving
the thread, I offer the

following to those who insist that strangers convert
their files properly:

"He was right, dead right,

As he sailed along,

And he's just as dead now,

As if he'd been wrong."

Thanks.

In the meantime, if anybody needs a bunch of strangers
in London to convert their files sympathetically you can get our number
from the web site. Alternatively, you can go to a *real world printer* and
get an in-RIP separation, crap print job, a bill and that warm feeling from
perpetuating the myth that colour management is a waste of time.

"You're certainly trashing this printer on a very
skimpy one-sided explanation of

circumstances. While its clear that the printer at
least acquiesced to accepting

the RGB, its not really clear that he
"agreed" to, and its not clear what the

full communication between Alain and the printer
entailed."

"but that doesn't open him to the degree of
derision he's been receiving."

I haven't read derision anywhere in this thread.

I don't agree anybody is "trashing this
printer." Why are you are writing so pronouncedly one-sided for
the printer? None of us needs a flame. As far as your use of 'agreed
to' regarding the RGB, that is implicit in the printer's acceptance
of the work. No customer needs to be an expert or anticipate the supplier's
mind.

On 7/2/03 at 12:59 PM -0400, John Romano wrote in a
message entitled "Re: [colortheory] Re: Who's at fault?":

You also need an application that can use Device links
and one to create a good one that doesnt reseparate through lab. But for
loose color that the client wants to see proofs on that are supplied from
god knows where I prefer to manage them in Photoshop. If I get a sep that
was prepared for 20% dot gain it would be flat and washed out, if i
have a profile to convert to our specs it gets the right numbers for
our press conditions.

John,

What are the considerations between doing that and
applying a transfer curve to match the dot gain?

Sorry, but I've seen lots of derision in the thread,
and I wasn't really looking just to take the printer's side, and certainly
didn't intend to flame anyone, I was just trying to imagine the actual
situation and what the printer may have been faced with.

While there needs to be accountability on the supplier
end, a customer has to accept some responsibility as well. If a customer
brings a one-color hardcover book to a full color ad shop or a critical ad
to a stationery shop, the customer has made a mistake. The printer has to
let the customer know that its not their niche, but the customer has to
make sure the printer has enough information about the job to realize that
before the project snowballs. I don't see why a supplier should be required
to anticipate the customer's mind either.

As to rgb, we still don't know the full circumstances,
if the printer had agreed beforehand to accept rgb that's one thing, if the
printer was under a misconception about the job and was later faced with
rgb that he thought he was told not to worry about, that's another. From
Alain's latest post it would seem the printer had rarely ever opened
photoshop, though there are other indications that would seem to say that
couldn't be true, Alain and/or the buyer should have have had enough
communication with the printer to have determined this beforehand for
themselves, they're serving as professionals too.

While I understand why the participants in the
"profile issue" get emotional, I've also noticed one very
significant "market segment" that's not included in any of the
discussions: photographers.

Not commercial photography, where the images will be
retouched and printed in books or magazines by the thousands, but portrait,
wedding, and school photographers. In those cases, "running a
proof" to identify the colors desired is just another way to double
the costs of every single image.

Some form of describing how a digital image's colors
should look is needed.

(Well, or have the lab correct the way they had been
doing for the last 30 years--by eye--which, unfortunately for most
photographers, very few labs will do.)

Are profiles "evil" in that situation? Can
anyone suggest an alternative?

I help a lot of digital photographers get their
colors to match, and without having to send a physical print along with
every file they send to their lab.

Maybe CMYK IS different--I don't do that much printing
to CMYK as such--but the heat generated in this discussion is making it
hard for the sparce facts to be convincing either way.

agreed, its a major mistake, but in my experience its
a mistake made more likely with embedded profiles in CMYK files.
Again, I'm ONLY talking about files already prepped for output where
no further conversion is needed.

How is

it more likely, let alone far more likely, that a shop
will convert

ONLY BECAUSE there is an embedded profile?

Because a profile mismatch is more likely to trigger a
warning that gives a user an opportunity to make a mistake than a missing
profile. An image with a missing profile will almost always be
treated first as though its in the shop's standard CMYK space. The reality
is that there is no profile mismatch in the situation I was describing.
My file will print fine; and most likely soft proof just fine, it
just wasn't made with a profile with identical characteristics as they one
they use as their working CMYK space...most likely different black
generation. Hell, we could even be using identical profiles that just
have different names. That could trigger an unwanted conversion that
will destroy any custom channel editing I may have done as the file is
re-separated. Maybe I airbrushed in black only drop shadows and the
re-separation turns them into four color shadows. I'm not saying this is a
likely scenario at all, but it has happened to me more than once.
I've never had any similar problem with an untagged, print ready
file. I realize that yes, unintended conversions can happen with
untagged files as well. I just don't see it as likely and my
admitedly very unscientific sampling of my experience backs this up.
If (very big if) the file I give them was properly prepped for their
conditions, it will look fine on their monitor and print fine on a
composite proof even though they may be assuming some other profile as the
source. Their assumed profile, their CMYK working space, describes
the same conditions that my file is targeting. We just may have used
different black recipes or for that matter may have just named our profiles
differently. If my file looks fine on their monitor there's not going
to be any urge to waste time as they look for a way to assign a profile to
this untagged file and convert it. They'll just print it.

How, specifically, would this occur *unintentionally*,
and do you have

any data to show how often this happens?

unintentional may have been a poor choice of words.
Unintended on my part... I didn't want it. The print shop may
well have actively (correctly or not) taken steps to cause the conversion.
Or it may be one of the automation issues that you referenced.

I have heard only 3rd hand

stories as though they were legend

It only has to happen a couple of times to worry me
and it has. In the worst case (meaning affecting many images on a
large job and the blame fingers were pointed squarely at me) the problem
was discovered in one of the early proofing rounds and easily corrected.
This was a case where an unwanted conversion was causing a color problem.
What was causing the conversion, I never was told exactly, but as
soon as I explained to the foreman how I had prepped the files and had
included an embedded profile he knew exactly what his production artist had
done and corrected the job quickly. The next batch of proofs were right on.

IMHO this hits the nail on the head. What's described
above is no different from two modems negotiating protocols before they
exchange data. This is the 21st century, we have the internet, cellphones,
etc. We should be communicating more, not less.

I wouldn't mind these color management discussions, if
they didn't cause the S/N ratio to drop like a rock. If a
[printer|customer] doesn't understand color management, you can either:

1: Call him names, or

2: Work together to find a solution, or

3: Find another [printer|customer]

I don't need a mailing list to tell me how to do #1.

[Hint: If you need to vent, write a response and
*don't send it*. After you've calmed down, if you still have something to
add, write a different one and send that instead.]
________________________________________________________________________

Date: Wed, 2 Jul 2003 21:39:47 -0400

From: John Romano

Subject: Re: Re: Who's at fault?

Rick

Getting the files close up front will let you still
use a transfer/ plate curve later on. The only time I like to go for plates
curves is if the press is having problems with paper or what ever, sort of
a last defense.We run linear plates 95% of the time. Dont get me wrong we
still use plate curves on rare occaisions, Our profiles are an average of
multiple presses and like I said it will get you very close.

But in the rare occurance you still have plate curves
in the end.

One other thing to mention, on supplied files. Some
can be UCR seps and some can be GCR or nothing at all. How do you think
this will print ? different set ups across the sheet. Sounds like a fun day
on press no ? Converting all supplied files is they way to go . If they
cant give you a profile, send them a target and make one yourself. Assign
and convert and your there. Im not a consultant, not that its a bad thing
here but I make profiles and use them in day to day production. If they
didnt work I wouldnt feel so strongly for them. Im done nothing left to add
here, Eveyone have a nice 4th and im sure this thread will die soon.

class of ICC profile) instead of two Output Device
profiles. Black only

can be retained, or even scaled (compensating for dot
gain between the

two black channels), preserve channel purity, etc.

Yes, DLP's sound good and we have briefly touched on
them before.

It's a pity that APS can't use them, though.

If the 'average' printer does not know what a ICC
profile is - what chance have we got that they will know about a DLP?
<g>

Not quite. BOTH the file numbers and color appearance
matter.

It is right, if all the printer does is open up the
layout and print the linked images with no colour conversion - the CMYK
values are simply passed on, as has traditionally been the case.

See above - I do not want
you [anyone, nothing personal] messing with

my CMYK values!!!

If the job wasn't separated for the specific print
condition, yes you

do.

I was talking of sending a known sep based on the SP's
guidelines.

Changing the supplied numerical colour data would be
as bad as changing a font.

If you're using their profile, and it gets embedded,
there will be no repurposing.

It is rare that a profile is given, more often
aimpoints or an Adobe profile preference is stated. It all depends on the
shop.

What do you care whether it's embedded

or not, so long as you know they're going to treat it
correctly?

I tag when the job is to supply a scan.

I often do not tag for a final layout image which is
in output.

By treating the CMYK tag correctly - no conversion
would be made of the data for film/plate setting. It is only for preview if
needed. I do not want a conversion, otherwise I would supply tagged RGB (if
it was accepted). The other use would be for digiproofing, where a
conversion from the CMYK source to the inkjet space is needed and a good
thing - but that is not the same as film/plate.

Since every image does not need a tag (the same one) -
it would be more beneficial to simply provide the single profile along with
the files (license restrictions may apply).

With a DeviceLink profile in place there is still a
conversion, but it's also possible to preserve certain things UNLIKE
regular Output Device profile to Output Device profile conversions; such as
black only drop shadows, text, preservation of channel purity, etc.

Changing the supplied numerical colour data would be
as bad as

changing a font.

It happens all the time, I think people need to get
over this obsession with device values. For all you know, the printer has a
bunch of presses and only gives you a general profile because they have no
idea what specific press it's going to be on until perhaps an hour or even
minutes before it goes on press. And what happens is your file ends up
going through either a DeviceLink or set of transfer curves to change your
numerical values anyway.

It is rare that a profile is given, more often
aimpoints or an Adobe

profile preference is stated. It all depends on the
shop.

Yes and just imagine if people treated fonts the way
some people on this propose we treat color management. If the industry were
so cavalier about fonts we'd have regular font disasters. Ooops! We do have
regular color disasters. I wonder why? Maybe it's because people are
unwilling to define responsibilities and stick to them, like we do with
font handling.

Since every image does not need a tag (the same one) -
it would be

more beneficial to simply provide the single profile
along with the

files (license restrictions may apply).

That's the point of PDF/X-1a. OutputIntent is
required. That is the source and destination for everything in the file.
It's either an externally referenced colorimetric definition or it can be
an explicitly embedded ICC profile. But it is required. You can't NOT have
it, and have a PDF/X-1a file. And PDF/X-1a is the press ready delivery
format. All colors are CMYK (or black), images must be embedded, fonts must
be embedded. And the point of the OutputIntent being both source and
destination is that it defines the data as being for a specific destination
which means a null transform. Only when the destination is different (which
should be only for proofing) is there a transform.

The reason why PDF/X-1a and PDF/X-3 work is because
there are clearly defined, and required responsibilities for the two
parties (print buyer and print supplier).

Under "What is DISC?" they say:
"We are recommending the Adobe RGB 1998

color space because it is large enough to
encompass most digital

capture, display, and output devices."
There it says

recommended, elsewhere it sounds like a
requirement. I'll see if one of

their contacts can clear up the apparent
contradiction<<<

There was a great deal of discussion about whether
it's better to "require" or to "recommend". As I
understand it the practice comes down to practicality, if a publisher has a
strong relationship with a photographer then there is little need for these
specs. But for new relationships, and to "guide" existing ones
towards some sense of simplicity workflow wise they thought it best to
create the specs. These are not meant as a threshold, as sole cause for the
rejection of an image. They are meant as a basis for communication, for the
exchange of files that cannot happen in a vacuum.

It's amazing to see how this thread dances with an
obvious point but just doesn't seem to ever get close enough to it. In this
line of work communication is essential. Without it disaster is inevitable.
Both client and vendor need to do everything necessary to be certain that
the expectations are set and met properly.

Whether it's best to embed profiles or not is just a
part of the communication. If a vendor assumes all images are in a given
space and has a workflow where inappropriate conversions may happen they
need to be very upfront with the clients on this. If they honor profiles
and expect them to be embedded then they need to be upfront about this too.
One way or the other it comes down to giving the other side the information
necessary to do the job right. If we substituted another subject for
profiles the need for communication would be obvious. Suppose I needed my
job printed on cardboard, but the printer assumed everything was going to
be printed on card stock. If I didn't tell him what to print on and he
didn't ask who'd be responsible? In rush circumstances these things happen
more often than we care to admit.

In the end if we want to stay in business we will
learn to communicate.

The problem is that they need to get work to pay
for the sales reps Mercedes

and are drawn like flies to a turd to the source
of some major image

problems: PHOTOGRAPHERS and DESIGNERS

Sure, life is always easier without the darn clients
and content providers. Of course without them there'd be no need for people
who express this insulting attitude either.

Still, I shouldn't grumble. It's good business
being an intermediary between

the warring factions [:-)]

This post sounds a bit like the arms merchant who
sells guns to both sides, laughing at what he thinks is their folly.
Laughing that is until he notices his whole world is burning as a result of
the war he's enabling.

Isn't business tough enough? Shouldn't we seek
out ways of working WITH each other instead of finding new ways of
squawking about how bad the other guys are? Where is the future in this
attitude?

Whether it's best to embed profiles or not is just a
part of the communication. If a vendor assumes all images are in a given
space and has a workflow where inappropriate conversions may happen they
need to be very upfront with the clients on this. If they honor profiles
and expect them to be embedded then they need to be upfront about this too.
One way or the other it comes down to giving the other side the information
necessary to do the job right.

This seems like you are spelling out a list of items
that should appear on any preflight checklist or printed communique or job
ticket. Of course the color management details belong there - and there
should be entries for it whether you use it or not. Why depend on
remembering to do this via word of mouth? The checklist approach means you
will be going over the list verbally, with both parties holding the same
information in their hands, when doing the usual phone conversation
followup.

To some people, communication aside from their
company's job order or checklist simply means, "So, how are the wife
and kids?" or "Did you see those Allstars?!?" Lists help a
lot to make certain the 'other' important stuff is covered before the
friendly schmoozing stuff takes over the left brain's activities! (Right
brain *rules* around here! <bg> )

But what then, if the client sends the printer an
untagged RGB file that

was created in a ColorMatch RGB working space? If it
is opened under the

assumption that it's untagged Adobe RGB, the result
before CMYK conversion will be

too dark and too strongly red.

Who said anything about giving untagged RGB? The topic
of this thread is, if you *do* give tagged RGB to a stranger, is there some
universal human right to the effect that the stranger is going to interpret
it correctly?

With the converse instance -- an untagged RGB file in
was created in an

Adobe RGB working space that is opened under the
assumption that it's untagged

ColorMatch RGB -- you'll have the result you
disparaged in the last Makeready

article: an overly light file that's weak in
saturation.

I had completely forgotten, until you brought it up,
that my last two columns are about situations just like this: where a
person assumes too much of his partner and fails to take elementary
precautions against the assumption being wrong. I illustrated this with
half a dozen catastrophes, one of them being exactly our case: the expert
embeds a profile from a wide-gamut RGB before handing it on to an unknown
printer; the printer ignores it; the job looks terrible; the expert calls
the printer names and bemoans his own bad luck in having to deal with such
incompetence.

For those who don't feel like having their jobs
destroyed in this fashion, there are two alternatives. First, if you feel
confident of your color skills, you can give CMYK. If that's undesirable,
convert your RGB file to LAB before handing it off to the stranger and tell
*him* to reconvert it to RGB. If he can't figure out what to do at that
point you certainly don't want him hacking away at your RGB file, tagged or
untagged.

It's all a matter of driving defensively, about having
the proper suspicions about other people involved in the process. Those who
do so may not think very much of their printer, but their jobs usually get
printed correctly. To quote that column:

"The next time you hear someone with impeccable
credentials wailing because a printer botched his job, or a client gave bad
instructions, or color management got screwed up, ask yourself: does it
seem like this person is consistently more unlucky than he should be?
Because if he is, perhaps it's not a matter of luck at all."

It's amazing to see how this thread dances with an
obvious point but just

doesn't seem to ever get close enough to it. In this
line of work communication

is essential. Without it disaster is inevitable. Both
client and vendor need

to do everything necessary to be certain that the
expectations are set and met

properly.

Yes, it's amazing that so much heat was generated,
considering that the basic premises are uncontested by anybody, to wit:

1) Client and printer definitely have to be a lot more
motivated to communicate with one another than this client and this printer
were.

2) It's a good idea for service providers to
understand what embedded profiles are and how they may be of use.

3) Nevertheless, a very large number certainly, and
IMHO a healthy majority, neither know nor care about the topic.

4) If a file prepared for Adobe RGB is misinterpreted
as being something else, the likely result is a ruined job.

Given those premises, one's course of action in the
real world seems obvious. Getting off on tangents as to how certain
operations *do* pay attention to profiles, or trying to make this into a
referendum on color management generally rather than on this tiny part of
it, serve no purpose. In fact, they are counterproductive in that they
imply to people like Alain that there's no need to prepare for the
likelihood that the printer won't honor the profile.

In my current column, which speaks to situations like
the one Alain engineered himself into, the headline reads as follows:
"Publishing today is very much a partnership game--but there's a limit
to how far you should trust your partner. Cater to the possibility that the
client, or the printer, may not be an expert, and you'll be a winner in the
long run."

The problem is that they need to get work to pay for
the sales reps Mercedes

and are drawn like flies to a turd to the source of
some major image

problems: PHOTOGRAPHERS and DESIGNERS.

Having spent the past 25+ years as both a photographer
and a graphic designer, I'm certain I've run into a couple of attitudes
like those above - but, thankfully, not many.

Keeping the lines of communication open between
design, prepress and print is a function I've personally put at the top of
the list since I first began in this business. Bringing in both downstream
functions at the outset of a project to discuss how everybody can make each
others life easier, while keeping the client (each of our clients) happy in
the process has totally eliminated the part of the process where everyone
points the finger of blame at one another (generally found at the end of a
project).

And guess what - everybody always gets paid to boot.

It's called the team approach. It requires the mutual
respect of all members to work. There's no place on our team for the kind
of attitude expressed above. The people we work with seem to appreciate the
fact that we ask for their assistance in getting things done that we may be
unfamiliar with - and they'll bend their own rules to help when needed. As
a result, most of the people we wind up working with actually look forward
to getting our files and clients wind up getting everybody's best efforts.

Saying one thing while meaning another is a something
that people have used to good effect in English for about 5 Centuries - I
guess that's why the plays of Shakespeare were so different from much of
the dull stuff that preceded them.

However, you are the second person to highlight one
particular sentence from my post and appear to attribute it directly to me
as if it were my own view. Fortunately your post did not lead on to a bunch
of idiotic insults like the one that Dennis Dunbar posted on Friday.

I chose not to respond to that post as the thread
looked like it was coming to a welcome end and verbally beating up somebody
who has both limited comprehension skills and less knowledge & ability
in this area than one of my trainees would have been embarrassing for the
*APA Digital Committee Chair*. (Little wonder he didn't bother to sign that
particular message with his official title!)

But, for the record, I'd like to point out that this
sentence does NOT reflect *my* attitude. It was an illustration of how
stuff can go bad when people take on work for which they do not have the
requisite skills to complete.

***BEGIN SARCASM ALERT***

I was forgetting that there are some English speakers
whose forebears spent the whole of The Enlightenment with their noses
firmly wedged in the pages of one particular book. For whom all sentences
must be plainly stated and truthful and for whom the such modern methods of
expression are incomprehensible.

...But, for the record, I'd like to point out that
this sentence does NOT

reflect *my* attitude. It was an illustration of how
stuff can go bad when

people take on work for which they do not have the
requisite skills to

complete.

I took the opportunity to respond to the remark
because it's far from the first time I've heard it. There are many people
in the graphic arts that share the view that their life would be infinitely
better if there were no designers or photographers to have to deal with.

In all honesty, there are a few designers I've met
over the years that I'd be reluctant to work with, too. Generally these are
the people who seldom wind up getting the results they want because they
lack the skills to communicate effectively with the people that must
produce their projects, and the talent to provide them with the materials
they need to realize their expectations.

But in the current world where we all share in the
benefits and problems of new technologies that are creating new ways of
getting our work done and blurring the traditional lines between functions
in the process, doesn't it make more sense to work in an atmosphere of
mutual respect and trust. It does to me.

As a photographer, the shift to digital imaging took
away my security blanket of an approved transparency to hand off for
prepress. CTP technology has made the search for a good yet inexpensive
method of proofing our files prior to release for prepress critical.
Without a good 'validation' proof (not a contract proof necessarily) we're
flyin' blind - and creating potential problems for the prepress people and
printer that means remakes and additional charges to the client.

The best way I've found to cope with the problems
presented by the new technologies is to share information - openly.
Communication allows everyone to progress and grow. Photoshop is a great
example. There must be three ways to do everything in Photoshop. Friends in
prepress are constantly surprised at how creatives use the program, and
creatives could often use a few of the methods prepress people use
everyday. For me, it makes every day I come to work an opportunity to learn
how to be a better designer, a better photographer, and a better resource
for my clients. The people that work for me have the same attitude - how
can we get this done; what resources can we use to solve this problem; who
in the production chain is likely to have seen this before?

After all, in the eyes of the client, we're all part
of the same problem - or part of the same solution. It's our choice.

After all, in the eyes of the client, we're all part
of the same problem

- or part of the same solution. It's our choice.

Well said, Jeff. I think that's the reason most of us
are here. Dan's the Man. Makeready put me on the right track and there are
others on this list who make valuable contributions from their own
extensive experience, as well, adding to the nourishing stew from which we
can all partake. I just wish some would refrain from tossing their large
egos into the pot, as well. Makes the stew taste bad.

Dolores

DGK Creative Imaging

And with that, there was a two-week ceasefire. But
hostilities recommenced in earnest with an even longer thread on handoffs
to strangers. See "Deliver in LAB" in this section. Meanwhile,
the question of whether CMYK profiles should be honored in the
absence of an instruction was answered by Photoshop CS, which by default
ignores CMYK profiles.--DM

Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.