Changes to Same as Source Printing - CS4

Report · Jul 06, 2009

Hello Everyone,

I'm in the process of testing CS4 for deployment to a large print production environment and I'm seeing some interesting behavoir in so far as it's handling of color management is concerned, specifically with Same as Source printing from Acrobat.

I currently have CS2 deployed, and we're using InDesign for page composition. We primarily accept Adobe RGB (1998) and US Web Coated (SWOP) artwork. PDFs are created from InDesign via File > Export, and we have it configured for "No Color Conversion" and "Include all Profiles." As such, our PDFs contain both RGB and CMYK artwork, all of which is tagged with an ICC profile.

In Acrobat 7, we submit these files "Same as Source" to our RIPs (Fiery and Wasatch) in order to preserve the embedded profiles. All of our color management is handled at the RIP. This works quite nicely. We have tested the submissions and the RGB and CMYK builds (color numbers) come through dead on.

With Acrobat 9 Same as Source submissions, we are seeing that the builds are changing, and that we are getting a conversion to CMYK.

-Original PDF file

Raster RGB - 191,45,47

Here are the numbers that are submitted by Acrobat, captured by our RIP:

-Acrobat 7 Same As Source

Raster RGB - 191,45,47

-Acrobat 7 Printer/Postscript Color Management

Raster CMYK- 0,244,245,0

-Acrobat 9 Same As Source

Raster CMYK - 0,242,251,0

-Acrobat 9 Printer/Postscript Color Management

Raster CMYK - 0,242,251,0

-Acrobat 9 Acrobat Color Management

Raster CMYK - 17,248,245,1

So the question is: What changes have been made in Acrobat 9 to cause for it to handle Same as Source print submissions differently? Why is it that our builds are changing when Same as Source has always been how we get "pass through" color from Acrobat?

Has anyone else run into this? From the perspective of a RIP-driven, color managed workflow, this is a serious issue, no?

Matt

Report · Jul 06, 2009

I hope that the suggestions that this group is dead are wrong...

We’ve done some further investigations into the differences in Same as Source printing from Acrobat 7 and Acrobat 9. For our tests we created a simple InDesign file with two red vector rectangles, one defined as Adobe RGB (1998) and one as U.S. Web Coated (SWOP). This file was then exported to PDF with “No Color Conversion” and “Include All Profiles.” The resulting PDF contained both rectangles tagged as specified, as verified with PitStop.

We then opened this PDF in both Acrobat 7 and 9 and printed to PS files (at the time, the queue for our HP5500PS was selected). Our cursory findings are:

1. The file sizes differs, which suggests that there is a difference right off the bat.

2. The printed artwork differs visually, which is troublesome.

3. In both instances, when opened in Notepad2, the page objects appear to be tagged properly with Adobe RGB and SWOP specified as the objects color space. This, on the other hand, is good.

a. Acrobat 7

i. RGB – Line 3342

ii. CMYK – Line 3400

b. Acrobat 9

i. RGB – Line 8406

ii. CMYK – Line 8468

4. And here's the biggie: When the PS file created from Acrobat 9 is opened in Illustrator, it says "The document does not have an embedded RGB profile" and it allows for the specification of an RGB profile ONLY. When the PS file created from Acrobat 7 is opened in Illustrator, it says "This document contains objects using both CMYK and RGB color modes. Illustrator allows only one color mode per document. Which color mode would you like to use?" Of course, this PS file SHOULD contain mixed color modes (because it came from a mixed color mode PDF), but only the PS files from Acrobat 7 do. The PS files from Acrobat 9 do NOT. This suggests to us that the PS files (and therefor print data submitted to PS queues as Same As Source) created by Acrobat 9 are not honoring the embedded ICC profiles of tagged artwork.

Does anyone out there have any thoughts or experience? If what we are finding is true, this is a major problem for Adobe's Acrobat 9 print engine.

Matt

Report · Jul 06, 2009

Files attached.

Report · Jul 06, 2009

Matt,

I wish I could answer your questions, but I do not have CS4. I'm still using CS2. I have seen a lot of posts on various forums lately, not only about CS4, but about LightRoom, OSX, Colorsync, etc, suggesting that color management is a bit of a jumbled mess at the present time. I'm not sure if it is global in nature, related to a specific O/S, software package, hardware, or what. All I can say is that something seems to be amiss, and it appears not all the vendors are on the same page.

I have seen posts about problems with double color management in LightRoom, interface problems between Adobe and Apple, color management problems with Vista, etc. If you have a business to run, I'd suggest waiting and doing a LOT of testing (like you are currently doing) before deploying. It's a good time to move slowly.

Sorry I can't be of more help. I am just recovering from a major computer crash and a switch from PC to Mac. It has NOT been smooth, but it does not appear to be an Apple issue. I won't bore you with the details.

Unfortunately, this forum is much more quiet since Adobe went to their new format. "Progress" of this sort is not always a good thing.

Lou

Report · Jul 07, 2009

Lou,

Thanks for your reply. Indeed, we are running though some pretty thorough testing, and generally this seems to be the biggest issue we've run into so far. That said, this would be a deal-breaker for sure.

If anyone else has had experience with this issue, or if there is anyone from Adobe monitoring these forums, I hope you will post here.

Thanks again,

Matt

Report · Jul 07, 2009

Acrobat 7 Printer/Postscript Color Management

Raster CMYK- 0,244,245,0

-Acrobat 9 Same As Source

Raster CMYK - 0,242,251,0

-Acrobat 9 Printer/Postscript Color Management

Raster CMYK - 0,242,251,0

-Acrobat 9 Acrobat Color Management

Raster CMYK - 17,248,245,1

What I do not understand is where you get a CMYK of 0, 242, 251, 0? Isn't a total ink amount going to max out at 100% per channel? That HP5500 comes with a RIP, no? I wonder why you are not using it? Perhaps you need a halftone dot, whatever. I would not recommend a mixed color environment, especially if you are trying to match color as in a proofing workflow. If you are in a Photographic workflow, then use the RGB colorspace. If you are in a proofing workflow, then use the CMYK colorspace.

As Lou has said in his post, there have been a lot of comments about CS4 and Leopard print issues. There are so many variables in play that it is extremely difficult to nail your specific problem per se. I've heard CS2 is very good. If there is a shift, whereas, all your color settings are the same in both CS2 and CS4 applications, their corresponding version of OSX, and your RIP(s), then it may be time to invest in a color calibration system.

I've worked with the HP5500 non-Postscript printer which required a third party RIP ( in my case, Wasatch 5 ) and Monaco Proof color calibration along with an xRite photospectrometer. Because I was in a closed loop CMYK proofing workflow, all of my files were CMYK going into the RIP and I am happy to report I achieved a fair amount of accuracy using a special media application and process. The reality is you are printing in CMYK with the added benefit of LM and LC, not RGB. The RIP is only interpreting information and converting that information in the driver. Photographic prints will print in a wider gamut than a CMYK proof and that's what is nice about inkjets. However, photographs print well in a CMYK colorspace, but will not exhibit as wide a gamut. I may or may not be drifting a little here, but I think you'd best invest in calibrating your system.

Report · Jul 07, 2009

John,

Thank you so much for your reply. I appreciate your time and expertise. We are using Wasatch 6.5, with ProfileMaker 5.0.8, an ES1000 with UV Cut, and an iO for convenience. We are in a fully calibrated and profiled environment, and have been for some time.

Apologies for the confusion with the CMYK builds. Those were provided to us by Wasatch support, and are being reported as 0-255 for each channel instead of 0-100%. This is a touch unusal, but you will see that you can get apps to report CMYK builds in this way if need be (including Photoshop).

In this instance, I do not believe that we are calling into question our Wasatch RIPing environment in any way. The problems are occuring before the Wasatch is even invoked, when Acrobat is generating the print data.

A) If we print the InDesign layout directly to the RIP from InDesign CS4, we see that the RGB vector is passed to the RIP as Adobe RGB (1998), that the CMYK vector is passed to the RIP as US Web Coated (SWOP), and that the color numbers remain intact. Needless to say, the print looks great. If we export a PDF from this layout and print it from Acrobat 7 Same As Source, we see the same behavior. Again, the print looks good. When we print the same file from Acrobat 9 Same As Source, we see that all of the colors are converted to CMYK, and that the color numbers are modified.

It is also worth noting that if we take the PDF exported from InDesign, and print it to file from both Acrobat 7 and Acrobat 9 Same As Source (files attached), we see the following behavior:

B) If the Acrobat 7 PS file is opened in Illustrator CS4, it rightly identifies that there are mixed color modes in the document.

C) If the Acrobat 9 PS file is opened in Illustrator CS4, it sees only RGB data.

Furthermore, when we investigate PS files in the Wasatch, we see PostScript Comments such as:

D) Submitted from Acrobat 7 - %Creator: PScript5.dll Version 5.2.2

E) Submitted from Acrobat 9 - %Creator: Adobe Acrobat 9.1.0

A, B, C, D and E all seem to indicate that Acrobat 7 and 9 differ in their treatment of Same As Source print submissions, and that Acrobat 7 is passing mixed color modes along, whereas Acrobat 9 seems to be doing some sort of conversion to a single color space. Further, it seems to suggest that Acrobat 9 and InDesign CS4 differ in their approach to printing the artwork.

What we are wondering is, what about Acrobat 9 specifically might cause for these discrepancies?

Thanks again for your time.

Matt

Report · Jul 07, 2009

Lou,

You're actually running CS2 under Leopard (OS 10.5.7) on a production machine??

Report · Jul 07, 2009

Nope. CS2 on Windows XP SP3.

Matt

Report · Jul 07, 2009

Ooops. Apologies. I didn't see that this was directed to Lou.

Matt

Report · Jul 07, 2009

Matt/Ramon,

I don't want to steal Matt's thread, so a quick answer only.

Actually I am using CS2 on WinXP SP3 (I thought you were psychic Matt). This is on my resurrected PC which crashed a month ago. I've been having huge problems with the OSX Canon driver crashing ALL applications when I tried to print from the Mac Pro (definitely not a Mac or OSX issue). I finally found a fix for the driver so am ready to move forward. I spent 3 weeks on this stupid problem. I seem to have been one of the first to see it, but others started having the same issue (newly released driver, but Canon didn't bother to change the version number, so it was not apparent. Duh!). So I don't have ANY version of CS yet loaded on the Mac Pro. I wanted to be sure I solved the interface problem before plunking down money for the Mac CS4 version.

Now, back to Matt's original thread.

Lou

Report · Jul 07, 2009

Just so you all know, I'm having another conversation about this here:

http://printplanet.com/forums/color-management/18523-changes-same-source-printing-acrobat-9-a#post11...

I also have an "important priority" support case open with Adobe, and I'm waiting to hear back from an Acrobat tech. I'll be sure to let you know what transpires.

I'm still curious to hear what others on the message boards think of this issue.

Matt

FYI - I am also running Master Collection CS4 on a new MacBook Pro and it rocks.

Report · Jul 07, 2009

It is also worth noting that the documentation for Acrobat 7 describes "Printer/PostScript Color Management" with EXACTLY the same text used to describe "Same As Source" in Acrobat 9.

So, they have definitely changed something big.

Forgive me if we are "thinking out loud" by posting our developments as they arise, but I want to keep the information in this thread up to date, as it is my hope that the community will have something to say about all of this.

Matt

Report · Jul 07, 2009

Scratch my previous post. I got bad info. The descriptions do not conflict, but the application behaviors do in the way that I have posted above.

Matt

Report · Jul 07, 2009

mattrichards wrote:
I hope that the suggestions that this group is dead are wrong...
We’ve done some further investigations into the differences in Same as Source printing from Acrobat 7 and Acrobat 9. For our tests we created a simple InDesign file with two red vector rectangles, one defined as Adobe RGB (1998) and one as U.S. Web Coated (SWOP). This file was then exported to PDF with “No Color Conversion” and “Include All Profiles.” The resulting PDF contained both rectangles tagged as specified, as verified with PitStop.
We then opened this PDF in both Acrobat 7 and 9 and printed to PS files (at the time, the queue for our HP5500PS was selected). Our cursory findings are:
1. The file sizes differs, which suggests that there is a difference right off the bat.
2. The printed artwork differs visually, which is troublesome.
3. In both instances, when opened in Notepad2, the page objects appear to be tagged properly with Adobe RGB and SWOP specified as the objects color space. This, on the other hand, is good.
a.       Acrobat 7
i.      RGB – Line 3342
ii.      CMYK – Line 3400
b.       Acrobat 9
i.      RGB – Line 8406
ii.      CMYK – Line 8468
4. And here's the biggie: When the PS file created from Acrobat 9 is opened in Illustrator, it says "The document does not have an embedded RGB profile" and it allows for the specification of an RGB profile ONLY. When the PS file created from Acrobat 7 is opened in Illustrator, it says "This document contains objects using both CMYK and RGB color modes. Illustrator allows only one color mode per document. Which color mode would you like to use?" Of course, this PS file SHOULD contain mixed color modes (because it came from a mixed color mode PDF), but only the PS files from Acrobat 7 do. The PS files from Acrobat 9 do NOT. This suggests to us that the PS files (and therefor print data submitted to PS queues as Same As Source) created by Acrobat 9 are not honoring the embedded ICC profiles of tagged artwork.
Does anyone out there have any thoughts or experience? If what we are finding is true, this is a major problem for Adobe's Acrobat 9 print engine.
Matt

Matt,

I think I see why you need PS, maybe to get proper device orientation?

I downloaded your PS files and distilled. The Acrobat 7 is all mystery meat. The Acrobat 9 is calibrated.

It looks like 9 is preserving all the tags, and 7 isn't. So the tags may be your problem. One option is decalibrating everything in Acrobat 9 but it's an extra step.

Maybe Don't Include Profiles out of ID would solve your problem BUT

To me it looks like 9 is doing the right thing (preserving tags), and 7 isn't. Generally you want calibrated output. Maybe your RIP is performing an extra unwanted conversion of the tagged content that's in the PS output from Acrobat 9...

Message was edited by: Printer_Rick - added "performing an extra unwanted conversion"

Report · Jul 07, 2009

Rick,

This is incredibly interesting, and in fact it was what I had been supposing, I just could never actually prove it.

Might you be able to tell me how it is that you identified that Acrobat 9 is tagging artwork and Acrobat 7 is not?

Essentially, I need to be able to explain to the RIP manufacturer (Wasatach), that yes, something has changed, but it has changed for the better and that they need to learn to handle it.

Thank you SO much for your explanation. I can't tell you how helpful this is.

Matt

Report · Jul 07, 2009

Rick,

I think I see it now. If I distill the PS files with a JobOptions set to no color conversion, I get tagged color from Acrobat 9 and device color from Acrobat 7.

Brilliant.

Matt

Report · Jul 07, 2009

Well, I may have spoke too soon. The official description of "Same as Source" in the Acrobat print dialog states that embedded profiles are ignored, and only device values are sent. That tells me that 9 should decalibrate all the tagged content on output, but it's not doing that.

For certain your RIP is treating this tagged content differently. There is probably a setting in the RIP you could change, but not being familiar with your RIP I'm not sure how involved that would be...

Report · Jul 07, 2009

Yeah - I read that, but it doesn't seem like that's accurate. Perhaps that was the description used for Acrobat 7 (which would be right) and they never updated it?

Mat

Report · Jul 07, 2009

mattrichards wrote:
Yeah - I read that, but it doesn't seem like that's accurate. Perhaps that was the description used for Acrobat 7 (which would be right) and they never updated it?

That seems to be the case. Adobe really should update these descriptions. It's little inaccuracies that lead to lost time and materials

It makes me think of another inaccuracy in ID. Say you open a document that is tagged with a source RGB that is different from your working RGB. Now output the file to PDF, Convert to destination. You get a warning in the summary: "The preset specifies source profiles that don't match the current color settings file. Profiles specified by the color settings file will be used"

That makes no sense whatsoever, at least not to me. A PDF preset doesn't have a source profile, it just specifies a destination. Furthermore ID will not use the source in your color settings, it uses the Document RGB (which it should). That warning is very misleading and needs to be reworded, it did a number on me one time...

Report · Jul 08, 2009

Rick,

I agree. The wording is confusing at best. I'll be sure to mention that to them during our conversation tomorrow. Luckily, I've gotten in touch with some high level Acrobat Output and Color Mangement Engineers, and they've taken interest in my issue. I will report back here with our findings.

So far, it looks like the changes to SAS printing from Acrobat 7 to 8/9 are all positive, and that ICC profiles are now included. While discussions with our RIP manufacturer are ongoing (they aren't particularly repsonsive, and in this case seem to be on the defensive unfortunately), my intuition tells me that they aren't set up to accept properly color managed output from A9...

I will be sure to update the discussion as I have more info.

Matt

Report · Jul 07, 2009

mattrichards wrote:
Rick,
This is incredibly interesting, and in fact it was what I had been supposing, I just could never actually prove it.
Might you be able to tell me how it is that you identified that Acrobat 9 is tagging artwork and Acrobat 7 is not?
Essentially, I need to be able to explain to the RIP manufacturer (Wasatach), that yes, something has changed, but it has changed for the better and that they need to learn to handle it.
Thank you SO much for your explanation. I can't tell you how helpful this is.
Matt

Unfortunately I don't have Acrobat 7, I only have 8 and 9.

I identified the difference by distilling the PS files, then viewing in 9. When I go to Calibrated in Output Preview, everything is there in the 9 version, but nothing is there in the 7 version.

You could have a color settings difference? Compare the color settings in Acrobat 9 and 7. If they are identical, then it looks like 7 is indeed discarding the tags.

This is a very interesting problem. "Same as Source" is supposed to be like turning off color management (that's the description anyway). So one could argue that preserving the profiles is the proper behavior, since you're not changing anything. But one could also argue that throwing out the profiles is turning off color management, too!

Confusing. In my opinion 9 is behaving properly, but it's different from 7, and unfortunately you had to find that out the hard way.

Report · Jul 07, 2009

mattrichards wrote:
Hello Everyone,
I'm in the process of testing CS4 for deployment to a large print production environment and I'm seeing some interesting behavoir in so far as it's handling of color management is concerned, specifically with Same as Source printing from Acrobat.
I currently have CS2 deployed, and we're using InDesign for page composition. We primarily accept Adobe RGB (1998) and US Web Coated (SWOP) artwork. PDFs are created from InDesign via File > Export, and we have it configured for "No Color Conversion" and "Include all Profiles." As such, our PDFs contain both RGB and CMYK artwork, all of which is tagged with an ICC profile.
In Acrobat 7, we submit these files "Same as Source" to our RIPs (Fiery and Wasatch) in order to preserve the embedded profiles. All of our color management is handled at the RIP. This works quite nicely. We have tested the submissions and the RGB and CMYK builds (color numbers) come through dead on.
With Acrobat 9 Same as Source submissions, we are seeing that the builds are changing, and that we are getting a conversion to CMYK.
-Original PDF file
Raster RGB - 191,45,47
Here are the numbers that are submitted by Acrobat, captured by our RIP:
-Acrobat 7 Same As Source
Raster RGB - 191,45,47
-Acrobat 7 Printer/Postscript Color Management
Raster CMYK- 0,244,245,0
-Acrobat 9 Same As Source
Raster CMYK - 0,242,251,0
-Acrobat 9 Printer/Postscript Color Management
Raster CMYK - 0,242,251,0
-Acrobat 9 Acrobat Color Management
Raster CMYK - 17,248,245,1
So the question is: What changes have been made in Acrobat 9 to cause for it to handle Same as Source print submissions differently? Why is it that our builds are changing when Same as Source has always been how we get "pass through" color from Acrobat?
Has anyone else run into this? From the perspective of a RIP-driven, color managed workflow, this is a serious issue, no?
Matt

Matt,

This looks to be a very complex issue. 2 questions:

1. You mention Acrobat 7 vs Acrobat 9. What about ID CS2 vs ID CS4, has that changed as well?

2. I'm curious why your workflow is ID – PDF – PS. Does your RIP not accept PDFs?

Just trying to get a handle on the problem...

Report · Jul 07, 2009

Rick,

Thanks for your reply. InDesign is uneffected, and submits the mixed color mode artwork correctly in both CS2 and CS4.

I'm not aware of any means by which we could submit the PDF directly to the RIP from Acrobat without going to PS. The driver that we are provided with by Wasatch is a PS driver.

Matt

Report · Jul 07, 2009

I'm surprised you cannot RIP a PDF. Although I preferred original source files ( in my case Illustrator EPS's ), I did RIP + PRINT PDF's occasionally. I also would not convert to PDF in the application, but would use Distiller to create the PDF. I would be interested in hearing what you discover via Adobe concerning your problem. Sorry I could not be more help.