Dan Margulis Applied Color Theory

Importing Grayscale Into PDF

   Date: Wed, 14 Apr 2004 10:27:55 -0000
   From: Stephen Marsh
Subject: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

Slightly off topic, but I found this 'interesting'...

I recently sent a client a CMYK PDF 'draft' (no colour values altered when distilling) of a four colour job.

They printed it out on their (presumably) RGB ink-jet from Acrobat Reader (again presuming) with no RIP (presuming again). The job was approved, as a stroke of luck I saw the ink-jet print and noticed something...

An imported vector EPS art from Illus8 (outlined logo text) had some letters that appeared to be a different colour than the other letters - when they should all have been the same.

The majority of the text was coloured in a _GREYSCALE_ build of 70k.

The letters which printed slightly different were in a _CMYK_ build of 0CMY70K.

Postscript printing and soft/hard proofing does not show any colour difference - not that I expect it too.

So I presume that this is a issue with a non PostScript printer printing a PDF file of mixed colour mode objects.

I adjusted the EPS file so that all objects were in GS mode and not CMYK, even though I do not think it is really necessary as I know that 70k is 70k if it is GS or CMYK at a RIP (this job will go to film).

Is this composite print behaviour 'common knowledge'? As my experience is PostScript based, this is new to me and unexpected.

Stephen Marsh.
___________________________________________________________________________

   Date: Wed, 14 Apr 2004 13:03:26 EDT
   From: Dan Margulis
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

Welcome to OSX (I assume it was OSX) color management, a minefield for non-PostScript (i.e. anyone who feeds a printer RGB data) users.

My friends in the color management community consider that OSX/ColorSync is a disaster area, because it insists on applying its own brand of conversion to the file even if the user doesn't want it to happen. So, it is assigning a ludicrously bad Generic CMYK profile to the CMYK file and then some other profile to the grayscale. Obviously, on the conversion the results will be quite different.

The problem is that some people use grayscale for conventional print, in which case the profile should be exactly the same as it is for the K of CMYK, and others for web or RGB output, in which case it shouldn't. A realistic color management system would not lump the two into one format.

As nearly as I can tell from the ColorSync list, most of those knowledgeable in the area consider OSX color management to be nearly unusable. Perhaps Chris can comment.

Dan Margulis

P.S. For those who are sending CMYK PostScript (i.e. printing out of InDesign or QXP) there are different problems, but ColorSync shouldn't get in the way.
____________________________________________________________________________

   Date: Wed, 14 Apr 2004 14:15:58 -0600
   From:Andrew Rodney
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

I1m not sure it1s usable or not but if Apple would simply DOCUMENT what the heck is going on, it be a lot easier to form an educated opinion. The ColorSync produce manager promised a 3white paper2 on the new features in Panther last year and as far as I know, nada. If anyone knows Mr. Jobs personally, please tell him we need someone inside of Apple to communicate what1s going on with regard to ColorSync under Panther. Looks like there are some interesting features but I have no idea what or how to properly use them. Chris?

Andrew Rodney
http://www.digitaldog.net
___________________________________________________________________________

   Date: Wed, 14 Apr 2004 15:01:46 -0600
   From: Chris Murphy
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

If this was printed from Acrobat Reader, the sequence of events for "color management" in this case are approximately as follows, ONCE YOU HIT THE PRINT button (i.e. none of this happens prior to hitting the print button, none of it affects the PDF on disk, just temporarily for print purposes):

1. Assumes untagged RGB is monitor RGB, and tags all such objects with the display profile.
2. Assumes something else for untagged CMYK and gray. The CMYK I think is SWOP v2 (so TR001), and gray I think is gamma 2.2. Those objects get tagged.
3. Anything with an actual tag in the PDF itself has its tag honored.
4. The whole document is converted to display RGB. Obviously the untagged RGB objects have the same profile as source and destination so they are not converted.
5. The now 100% display RGB data is submitted to the OS, with the display profile submitted as the profile for the entire print job. This means the OS will not propose to tag the job with a bogus Generic RGB profile, but doesn't potentially let ColorSync off the hook yet.
6a. If ColorSync is selected in the printer's  print dialog, a series of hens hidden in the computer generate a random number to determine what destination profile to use. The document is then converted by ColorSync using the display profile as source and the hen selected profile as destination, and once again the job gets converted. It's then passed onto the guts of the print driver at which point a bunch of other things happen but eventually something pops out of the printer.
6b. If ColorSync is not selected in the printer's print dialog (you use the default settings for example) the embedded display profile is invariably ignored, the print driver makes its own separate assumption about the source profile to use and does its own conversion and the prints the file.

So the problem you are experiencing could be a conversion that occurs almost anywhere. I suspect in this case its some obscure rasterizing bug in Acrobat Reader. Considering it takes any version of Acrobat (Reader through Professional) about 150 times longer to rasterize and print a document than either Apple's Preview application, or any version of Acrobat on Windows, anything is possible when printing from Acrobat.

But if you're really curious, what you could do is put the print queue on hold and print the file. Oddly enough, because everything in OS X is PDF based, Acrobat takes your high quality PDF and rasterizes it for the printer and submits that to the OS which in turn writes a PDF based spool file. If you dig around you can find that PDF spool file, and run it through Pitstop Pro to find out what's happening to the document before ColorSync gets involved in it. If the problem is there, it was caused by Acrobat. If not, then it's either an OS level glitch, or the print driver is doing something whacky. If you decide to do this, please let me know what you find out.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Wed, 14 Apr 2004 16:21:00 -0600
   From: Chris Murphy
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

On Apr 14, 2004, at 2:15 PM, Andrew Rodney wrote:

Im not sure its usable or not but if Apple would simply DOCUMENT what the
heck is going on, it be a lot easier to form an educated opinion. The
ColorSync produce manager promised a white paper on the new features in
Panther last year and as far as I know, nada. If anyone knows Mr. Jobs
personally, please tell him we need someone inside of Apple to communicate
whats going on with regard to ColorSync under Panther. Looks like there are
some interesting features but I have no idea what or how to properly use
them. Chris?

Basically it's a task in trying every combination of options to find out what works and what looks like it works but doesn't. Any professional that's reasonably sane will have far better things to do with their time, and will use professional tools. The architecture basically requires applications to do the wrong thing, the operating system to do the wrong thing, the end user to do the right thing in at least two locations and the print driver vendor to do the right thing, in order for color management to occur correctly. And when Apple's own applications deviate from from this it's any wonder there is vendor confusion.

Basically it looks like various bugs will prevent filters from being all that useful. The pre-built ones work fine, if you like them, use them. What really gets me is that we're six months into the life cycle of Panther and there is still no documentation, and still no bug fixes for major bugs (like the PDF/X-3 feature that doesn't make a PDF/X-3 compliant file). At this rate, these bugs will likely exist for the entire 10.3.x product lifecycle. It undermines international standards, it undermines workflows, it undermines Apple's credibility. The only silver lining is that almost no one will use these features anyway so they're unlikely to get hurt.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Wed, 14 Apr 2004 18:53:39 EDT
   From: Dan Margulis
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

Chris Murphy writes,

Basically it's a task in trying every combination of options to find
out what works and what looks like it works but doesn't. Any
professional that's reasonably sane will have far better things to do
with their time, and will use professional tools. The architecture
basically requires applications to do the wrong thing, the operating
system to do the wrong thing, the end user to do the right thing in at
least two locations and the print driver vendor to do the right thing,
in order for color management to occur correctly.

I would add, that Apple's new variation on the old color management theme of turning what should be a simple concept into a boobytrapped mishmosh has a particularly nasty sting, in that the people it affects (those who aren't in a CMYK PostScript workflow) tend to be those who are least likely to be able to figure out WTF is going on. When it snares an experienced user like Stephen, how in the world does anyone expect that some photographer who just bought his first serious printer is going to get it right?

Dan Margulis
___________________________________________________________________________

   Date: Thu, 15 Apr 2004 10:14:13 -0000
   From: Stephen Marsh
Subject: Re: 70% grayscale vs. 0CMY70K (RGB ink-jet prints from PDF)

Dan Margulis writes:
 
I would add, that Apple's new variation on the old color management theme of
turning what should be a simple concept into a boobytrapped mishmosh has a
particularly nasty sting, in that the people it affects (those who aren't in a
CMYK PostScript workflow) tend to be those who are least likely to be able to
figure out WTF is going on. When it snares an experienced user like Stephen, how
in the world does anyone expect that some photographer who just bought his
first serious printer is going to get it right?

I found this interesting for the following reasons:

* I had ensured that the CMYK values in the job were 70% K for the required elements...some were Illus8 EPS files and some things were native Xpress elements.

* In-house proofing, in both composite and separated CMYK tests indicated that all the elements from mixed sources were indeed 70K and that they all appeared visually the same.

* The PDF looked correct on the monitor - in how the 70K elements were all displaying the same apparent colour (but I may have to double check this...).

*** It was sheer chance that I saw the clients print of the PDF!!!

If I did not see the RGB inkjet print, then I would have had no reason to flight-check the file further than I had previously. My inspection indicated that the required tint value was common to all foreign elements, but I did not notice that the imported vector file had some elements in GS and some in CMYK colour model builds...it was all 70K to me, but not obviously the same composite appearance when printed in a non PS setting.

CMYK PostScript does not indicate this as a colour difference from Xpress...not sure on the PDF, again I will have to see.

I knew that film output would not have any problems with the mixed source of 70K vs 0CMY70K...but I made it all grayscale build anyway, so if this is printed on a RGB pipeline in the future the issue will not be there.

Stephen Marsh.
___________________________________________________________________________

   Date: Thu, 15 Apr 2004 10:03:05 -0000
   From: Stephen Marsh
Subject: Re: 70% Greyscale vs. 0CMY70K (RGB ink-jet prints from PDF)

Chris Murphy wrote:

If you decide to do this,
please let me know what you find out.

Thanks Chris, but I am in a OS9 CMYK PostScript setting and these tests are beyond me.

Thank you for your detailed post, from what you and Dan have said I think I can see what may have happened - but I am presuming that this was printed from classic, but I don't really know.

Stephen Marsh.
___________________________________________________________________________

   Date: Fri, 16 Apr 2004 11:02:11 -0600
   From: Chris Murphy
Subject: Re: Re: 70% grayscale vs. 0CMY70K (RGB ink-jet prints from PDF)

On Apr 15, 2004, at 4:14 AM, Stephen Marsh wrote:

I knew that film output would not have any problems with the mixed
source of 70K vs 0CMY70K...but I made it all grayscale build anyway,
so if this is printed on a RGB pipeline in the future the issue will
not be there.

I will bet money this is an Acrobat and RGB output device problem. Acrobat by default assumes grayscale has gamma 2.2 behavior. So 70K only will behave not like ink, but like gamma based grayscale. 0C 0M 0Y 70K on the other hand will  have the simulated behavior of ink (specifically SWOP v2 black ink tone response). On-screen it may not be as apparent as in print either.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor

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