Changes to Same as Source Printing in Acrobat 9

[Matt Richards]

Hello Everyone,

I'm in the process of testing CS4 for deployment to a large print production environment and I'm seeing some interesting behavior 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?

(This is also posted to the Color Management forum, as it is both a color management concern generally, and an issue specificly related to Acrobat.)

Matt

 

[Matt Richards]

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.

Files are attached.

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

 

[leonardr]

I'm in the process of testing CS4 for deployment to a large print production environment and I'm seeing some interesting behavior 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.

Are you exporting as standard PDF or as one of the PDF/X variants? if PDF/X, which one? If standard PDF, what versions?

Do you documents contain any transparency? Any use of overprinting?

In Acrobat 7, we submit these files "Same as Source" to our RIPs (Fiery and Wasatch) in order to preserve the embedded profiles.

So first thing you need to understand is that Postscript does NOT support profiles - so that it may be IMPOSSIBLE to preserve embedded profiles "intact". Instead, what happens (in most cases) is that the profiles are converted into Postscript's classic color management methods. There are Adobe extensions to Postscript that enable "pass through profiles" which may or may not be in use.

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.

Then wouldn't it make more sense to simply submit the PDFs directly to the RIP via a "hot folder" or similar workflow - why bring Acrobat into the mix to force it to convert to Postscript? This is especially true for when you move to a native PDF-based printing solution (eg. Adobe PDF Print Engine).

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?

In Acrobat 8 we made major changes to how printing takes place to bring Acrobat and the rest of the Creative Suite inline with each other - so that there is (since CS3) complete consistent color and printing handling among the applications in the suite.

Leonard

 

[leonardr]

Oh, and one more question - Mac OS or Windows? What version of the OS?

Leonard

 

[Matt Richards]

Leonard,

Thank you for your reply. I've posed to a number of different forums (including the Adobe Forums) and yours is the only reply I've had. I'm incredibly grateful for your time and expertise.

1. Platform: Windows XP, SP3

2. We cannot use hotfolders, and must use Acrobat, because we have a very large number of people (~300) submitting jobs to this workflow. Acrobat is established as our "print platform" and there is a lot of training and other related print processes that rely on it.

3. There is no transparency in our test file, which is attached.

4. Our PDF creation settings for export from InDesign were initially based on PDF/X-4, but do not conform to that standard explicitly.
- Version 1.5 (Acrobat 6)
- Create Acrobat Layers
- No Color Conversion
- Include All Profiles
- I have attached the .joboptions file

I'm very glad to see that Adobe is working on building consistent print behavior between all of the CS apps, but it seems as though we are seeing otherwise. Perhaps you can show us the error of our ways:

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.

A, B, and C all seem to indicate that Acrobat 7 and 9 differ in their treatment of Same As Source print submissions, and that Acrobat 7 is rightfully 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 about Acrobat 9 specifically (or perhaps about our process) might cause for these discrepancies?

It may very well be that we have a critical misunderstanding of the underlying processes here, and if that is the case, I apologize. We really appreciate your patience and time.

Thank you again for your response and assistance.

Matt

 

[Matt Richards]

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

A) Submitted from Acrobat 7:
%Creator: PScript5.dll Version 5.2.2
4 RGB images present
1 CMYK images present

B) Submitted from Acrobat 9:
%Creator: Adobe Acrobat 9.1.0
0 RGB images present
5 CMYK images present

This too seems to suggest that there is something very different going on with 7 and 9.

Matt

 

[rich apollo]

Matt,
What printer and printer driver are you using?

 

[Matt Richards]

Rich,

The printer is an HP 5500 PS. We are submitting the jobs to a Wastach 6.5 RIP via a the "DesignJet 5500 Series for RIP" which is supplied by Wasatch.

Driver name: PSCRIPT5.DLL
Data file: hpdj5500.ppd
Config files: PS5UI.dll
Help File: PSCRIPT.HLP
Driver Version: 6.00
Environment: Windows NY x86

Matt

 

[Matt Richards]

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

 

[Matt Richards]

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

 

[leonardr]

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

A) Submitted from Acrobat 7:
%Creator: PScript5.dll Version 5.2.2
4 RGB images present
1 CMYK images present

B) Submitted from Acrobat 9:
%Creator: Adobe Acrobat 9.1.0
0 RGB images present
5 CMYK images present

This too seems to suggest that there is something very different going on with 7 and 9.

I don't know anything about this "Wasatch" program, but we took at look at the Postscript files that you had previously posted and it was quite interesting to note a difference in the A9 and A7 output files in how the colors are tagging (or not).

Both files had the same RGB vs CMYK behavior. However, the A7 output didn't have any calibrated color. It looks like A7 SAS printing stripped off the color profiles while A9 SAS printing passes-through the embedded profiles.

You can also verify this (as I did) by taking those same .ps files back through Distiller using a JobOptions settings where color is set to "no changes" and then checking the PDFs. You will find that in the PDF based on the A7 output, both rects are now device colors while the converted A9 output file is still 100% ICC-based.

This would therefore imply that the problem is NOT in Acrobat, but is in the way your RIP is configured to handle calibrated vs device color. Can you check what/how your RIP handles such things? As I mentioned earlier, not all RIPs fully support "Postscript color management" or Adobe's extensions for included profiles - and that may be what you are seeing here and why you didn't see it with Acrobat 7.

Hope that helps!

Leonard

 

[Matt Richards]

Holy smokes Leonard. I cant tell you how much that helps. Why didn't I think about the Distiller check on the PS files?!?! Brilliant.

I had supposed that Acrobat 9 had indeed changed the way that it was handling SAS, but that it was probably a change for the better, and that the RIP manufacturer (Wasatch) was the one with no idea what was going on.

I am going to check into how the RIP handles these situations. You may very well be right that it is not built to handle fully ICC-color managed artwork.

Again, thank you so much. This is an amazing help. I will post back with my findings after having talked to Wasatch.

Matt

 

[Matt Richards]

UPDATE:

We have run through the following steps to verify the output from Acrobat 9 (A9) and compare it to that of Acrobat 7 (A7).

1. Created an InDesign artboard with two vector rectangles. One is RGB (AdobeRGB (1998)) and the other is CMYK (US Web Coated (SWOP) v2). The color numbers were 255,0,0 and 0,100,100,0 respectively.

2. Exported a PDF with the settings below. These settings yield a PDF with the two rectangles colored and tagged as they are on the InDesign artboard (mixed color modes)
- Version 1.5 (Acrobat 6)
- No Color Conversion
- Include All Profiles

3. This PDF was then opened in A7 and A9 and printed to two PS files, specifying the HP5500 driver, and SAS in the Advanced print settings.

4. These two PS files were then distilled using a .joboptions file that specified “No Color Conversion.”

5. The result was that the PS file from A7 generated a PDF with DeviceCMYK only, and the A9 PS file yielded a PDF with both vector rectangles colored and tagged properly with AdobeRGB (1998) and US Web Coated (SWOP) v2.

As such, we can see that Adobe did make a change, but it was a change for the better. A9 is an improvement over A7 in that it provides true pass-through color via SAS printing, and preserves all embedded ICC profiles in a mixed color mode print submission. This is in comparison to A7, which did not honor these profiles, and seems to have done a conversion to DeviceCMYK/RGB when artwork was submitted SAS.

This would therefore imply that the problem is NOT Acrobat, but may be in the way the Wasatch RIP is configured to handle ICC vs device color.

I must say, I have been very, very pleased with Adobe's response to this issue. We are in the process of coordinating with a handful of Acrobat engineers (who focus on output and color management) to verify the test above and try to identify what might be going on once the data has left Acrobat.

A question for the group: Might it be that the underlying PS level used by the RIP is PS2, and that the ICC profiles are not being converted to PS CSAs because it is not a P3 RIP?

Unfortunately, the RIP manufacturer (Wasatch) has been less-than-helpful, and turnaround on their support is often more than 24 hours. As such, I can't even find out the basic information about this product, like what level of PS it supports, or how they are configured to handle ICC managed color, if at all!

Thanks to everyone for your help. Any thoughts on the question above are appreciated. I will be sure to update the group as we learn more about what is going on.

Thanks again,

Matt

 

[rich apollo]

Matt,
The configuration of the Wasatch RIP software's color controls is up to the user - it is ICC aware, though. According to the specs (on their website) the software supports PostScript level 3.

I Distilled the PostScript files you posted and got RGB and CMYK in both resulting PDFs. The difference I found is that the output from Acrobat 7 created PDFs with no ICC Profile - the output from Acrobat 9 led to PDFs that had ICC Profiles embedded. It looks like there's information in the PostScript file that will retrieve the ICC profiles when needed. If the profiles aren't available, then I guess the CSAs are used. For example, if I uninstall the ICC Profiles before Distilling the PostScript, I get appropriate color, but no ICC Profiles in the PDF.

The output has changed from Acrobat 7 to Acrobat 9, and I guess the question is, "How is the RIP handling the new instructions?" Are you expecting the RGB and CMYK rectangles, from your example, to match on the printed piece? Or are you trying to achieve the same output that you got from Acrobat 7?

Your RIP may have been assuming different source profiles than what are currently being embedded. You may also need to be sure that the appropriate profiles are (or are not) installed on the Wasatch box. Lastly, you may wish to set up Wasatch to disregard embedded ICC Profiles - as it looks like it didn't have any embedded profiles to make use of before. If you want the rectangles to match one another I believe you'll have to set up a Simulation Profile for the RGB elements.