Certainly this is a bug in Acrobat X. I also tried to report it to Adobe Support for Czech, but it seems that they did not understand me. : (
Below I send what I learned and how you called Adobe bug.
"Adobe Acrobat X not change the CMYK values Will change only the output intent profile. It's nice to see in theses videos.
Acrobat 9 Pro - functional colormanagement - http://screenr.com/3T08
Acrobat Pro X - not functional colormanagement - http://screenr.com/eT08
Well my case Adobe Support and ended with this: bug # 2921089 and the description says "wrong color preview from InDesign / Illustrator created in Acrobat PDF opened X".
But it's not a bug in the preview, but That does not change Acrobat at all values of CMYK source profile to the profile of the target. "
Thanks so much for your reply Ales. Those videos show exactly what I am experiencing and I am on a Mac. It is good to see that it is not a OS or platform issue.
Your description of the problem is absolutely the same thing that I am experiencing. The Preview Output Intent changes, but the actual cmyk values stay unchanged. This has been quite frustrating since I started testing Acrobat X.
I use the "convert to output intent" function frequently to properly color manage all of the pdf documents that I process quickly, so until this is fixed I am forced to stick with Acrobat 9 for this workflow.
Thanks again for helping to confirm this issue. I hope that the Acrobat team at Adobe takes notice.
I use this every day and because I work in textile printing and color printers we have not Cyan, but the color of dark blue, colormanagement I use for all graphics.
Yup, it's pretty serious to me that fault and unpleasant. But I found a solution by which to circumvent this, than it corrects. At least I hope not call it a new feature of version X.
There is no problem. Here you can download my files that I used on video and I also sent to Adobe support. File number = case number for Adobe support.
In my opinion, Acrobat X is doing the right thing and Acrobat 9 had the bug.
You can verify this by open the PDF up in Acrobat 9, open Output Preview and then switch the simulation profile to your custom one. The circle will go dark, since (apparently) that’s what your profile wants.
Color Conversion makes that change permanent by changing the color values in the PDF as well as (in this case) adding an OutputIntent profile to the PDF.
I beg to differ.
The color source data with ISO Coated profile is light blue (100/20/0/0).
My goal is to convert this light blue color to the new profile to remain as faithful as possible to color. (ie change to a different CMYK values, but with the visual appearance was the closest source data)
Acrobat 9 will do this. Changes to the CMYK values (81/2/10/4). The CMYK values with my new profile 2M MULTIFLAG Sansient have 9.11.2010.icm ICC (which is now as the output intent) look almost identical, as the source CMYK values (100/20/0/0) with the ISO Coated profile. This is the correct procedure.
With Acrobat X CMYK values unchanged. Remain original (100/20/0/0). With these values the object profile using 2M Multiflag very dark.
Imagine if I get a picture in the ISO Coated v2, and I need to print it out on our printer profile Multiflag 2M. The result would be unusable. Therefore, all images in Acrobat 9 is transformed to a new profile (CMYK values will change) and immediately see whether the photo to use.
You are misunderstanding how color management work.
The provided file (Test.pdf) uses DEVICE CMYK values (). They are NOT defined in any specific profile – hence the “DeviceCMYK” aspect. They will, however, be displayed by Acrobat as if they were values associated with whatever working space profile you have chosen. In your case, that appears to be ISO Coated, in mine it’s SWOP. So already our blues are different.
As you note, when you use the “Convert to OutputIntent” choice, you are NOT actually changing the CMYK values of the object – BUT you are instead making it explicit what profile to associate those values with. This is equivalent to “Assign Profile” in Photoshop. So the values in the PDF remain unchanged (), BUT NOW instead of either ISO Coated or SWOP – it’s in your MULTIFLAG profile.
IF, HOWEVER, you use the actual Convert Colors part, but setting the profile in the Conversion Attributes, and then converting, the CMYK values in the PDF will change (to ) to what they would be for that same color according to MULTIFLAG…HOWEVER, Acrobat is still displaying them according to ISO Coated/SWOP as they are still DeviceCMYK colors.
If you want the correct values associated explicitly with MULTIFLAG, then also click the “Embed” checkbox which will them embed the MULTIFLAG profile along with the image and its newly converted value.
In that case, you have to admit that what he did Acrobat 9 is better. When I had to convert color values changed to CMYK target profile and assign the profile to which I was transformed. I immediately saw that the transfer was carried out correctly. I know that the source profile used what I had set in the workspace. When there was a client Swop, I set to SWOP Acrobat 9 to convert and put into Multiflag. I immediately saw how it's transferred and could check the result. Then I could save the file as PDF-x1a abyl correct.
If that's the way you write, you can explain to me why there is a possibility: ""Preserve CMYK primary colors" - "preserve black"", when you say, only the final plan, the equivalent of Photoshop "Assign Profile"?
Actually, the right thing would be for “Convert to OutputIntent” to be dimmed UNLESS the PDF already had an OutputIntent included, as the purpose of the feature is to convert all of the OTHER colors in the PDF to that of the OutputIntent. This is useful when dealing with PDF/X or PDF/A compliant files.
And in that case, the Preserve options would be perfectly valid.
In your case, the file only has DeviceCMYK colors and NO OutputIntent – so it’s being used improperly. I’ll file a bug to dim the item.
This is what Adobe help documentation states:
- Select Convert Colors To Output Intent and specify the output intent profile to convert every object to the output intent. An output intent describes the color reproduction characteristics of a possible output device or production environment in which the document is printed.
- Specify the pages to convert.
- Select a conversion option if applicable:
- Preserve Black
- Preserves the color values of objects drawn in CMYK, RGB, or grayscale during conversion. This option prevents text in RGB black from being converted to rich black when converted to CMYK.
- Promote Gray To CMYK Black
- Converts device gray to CMYK.
- Preserve CMYK Primaries
- When transforming colors to prepare CMYK documents for a different target print profile, preserves primaries. For colors with just one colorant, Acrobat uses that colorant. For colors with more than one colorant, Acrobat finds the color with the smallest color difference.
Let me repeat in #1 ... "convert every object to the output intent"
It does NOT say "assign".
It does NOT say "OTHER colors".
It is useful for converting ANY pdf, NOT just pdf/x or pdf/a.
It absolutely does NOT require that an output intent was already included in the existing pdf.
I have been using this feature successfully in Acrobat 9 literally every day for years, but it is clearly broken in Acrobat X as no cmyk objects get converted to the output color spaces cmyk numbers as they did in Acrobat 9.
Are you suggesting that Acrobat 9 was broken for it's entire life cycle?
Why are you trying for us to not have this fixed Irosenth?
What is the drawback for you if this feature gets fixed in Acrobat X?
Why the animosity?...
Please continue to respond if you have a solution that will help us solve this problem. Repeatedly asserting that we have no problem is not really helpful. Let's not argue, let's work together.
To answer the questions
>I have been using this feature successfully in Acrobat 9 literally every day for years, but it is clearly broken in Acrobat X as no cmyk objects get >converted to the output color spaces cmyk numbers as they did in Acrobat 9.
>Are you suggesting that Acrobat 9 was broken for it's entire life cycle?
Yes. Acrobat 9 is broken and Acrobat X fixed it.
>Why are you trying for us to not have this fixed Irosenth?
Because we already fixed it in Acrobat X, so there isn’t anything else to do.
"we already fixed it" ... ???
We who? Are you an Acrobat programmer? If so, then you have my admiration because it is a really awesome program.
In Acrobat 9 "convert colors to output intent" performs exactly as the help file describes, and now in X it is completely non-functional for already cmyk pdf documents other than soft-proofing cmyk numbers by only embedding an Output Intent profile that may or may not match the actual color space of the document if it started out in cmyk.
How do you explain the disparity of the Adobe help instructions and what you are saying is the proper functionality here?
I can understand if you wanted the ability in Acrobat to embed an output intent profile without making a conversion of the color numbers. In fact this is a very useful function of the Output Intent panel of Enfocus Pitstop. The problem that this presents in my opinion is the removal of the functionality present in Acrobat 9 and described in Adobe help to accomplish that goal if that is what you are saying.
How am I to make such effective and quick cmyk to cmyk conversions of entire pdf documents without making all of the black text 4-color process if I do not use the functionality in Acrobat 9 or the functionality described in Adobe help? If what you say is true and you inadvertently created an extremely useful functionality by accident in Acrobat 9 that is no longer available in Acrobat X on purpose then that is very unfortunate for my workflow.
I think that you are confused since the help describes Acrobat 9 functionality perfectly.
How do you explain away the preservation of black that occurs in 9 and as described in the help?
Why would you even need to preserve the black if no change in cmyk color numbers is made?
If you convert an RGB document to an output intent in X it converts the color to the cmyk numbers determined by the output intent profile that you chose in the dialog. With the functionality in 9 I could in one simple step convert every cmyk object in the pdf except for black text into any particular press's profile space creating cmyk numbers that would print perfectly with the intended color just the same as if the original document had been all RGB.
So now in X if I want to convert all of the cmyk raster and vector objects in a pdf document to a specific cmyk profile in one easy step without converting all of the black text to 4-color process, I am basically screwed.
How do I put in a vote to revert to the so-called broken functionality or have it added as an extra functionality in addition to the simple embedding option that you now state this was intended to be for profiles in the same color space.
Well then perhaps I am the one that is confused. I guess I am just frustrated that I made this Acrobat 9 functionality such an integral part of my prepress workflow, and now I will have to find a work-around that can mimic this without too much extra effort.
That is why I have such thoughts that it is now "broken", because it is no longer doing what I want it to do and what it has done for a few years now. I certainly appreciate Leonard's patience trying to repeatedly explain where I am going wrong in my thinking.
The disparity in total ink densities of "USWEB swop coated v2" cmyk space that 99.9% of agency pdf files are supplied in and the total ink densities and hue shift in many of our destination press profiles dictates that I must make cmyk to cmyk conversions on all of our supplied files before printing. As you can imagine, the ability to make this conversion while retaining the black plate even on files with flattened transparency and shadings while retaining perfectly black only text where required has been quite handy. In fact it has made many excellent printing reproductions possible that would have been more difficult during prepress work without the Acrobat 9 functionality of this tool.
I am certain that I can eventually work around this change as always. This one has just been a bit more challenging than others because the regular color conversion in the top section of the convert colors dialog can be quite unreliable and often fails to covert colors in overlapping images and shadings to the same values causing color mismatches in transparent areas even if I have seemingly tagged every single object with a correctly matching source profile. It can be very tricky to get everything to match like it does in the Acrobat 9 convert to output intent function. Ultimately even if I can get that difficult process to work for the entire document, I then have to go back and fix the now 4-color process black text that can be tedious in documents with live transparency already flattened. It is going to be a lot more work now to get these files prepped properly.
It is quite ironic that a malfunction could prove so useful and efficient in a prepress workflow for so many years. In fact, we will probably continue to use Acrobat 9 as long as we can reasonably do so in order to keep the efficiencies provided by this broken tool.
Once again, Thank you to Leonard for your patience in trying to explain your changes to this tool in Acrobat X, and I apologize for times when my communications come across as overly confrontational.
I still want to put my vote in to go back to the broken version of this function....
Also, the power to intercede as you return to this poor functionality. For many years I use it and now we are forced to return back from version X to version 9, where I'm working.
Thanks Dallas, helping me with explaining this to us useful functions. My English is bad so I did not already know, how do I explain to Mr. Iroseth me why the error according to Adobe, according to property suits me great. I use it for the same purpose as you. Thanks again.
Let’s forget about the help file – that’s written by a completely different group who don’t always talk to engineering & product management ☺.
The issue here is what is the correct behavior.
In Acrobat 9, you could only do a single thing – convert colors to a given profile. And you could that in two different ways – either using the standard Conversion Commands OR via the Convert to Output Intent. The difference between the two being that the Conversion Commands could be used on a subset of the objects (say only those in CMYK) while Convert to OI would convert all objects AND also embed the OI (which isn’t useful for non-PDF/X or PDF/A files). BUT in the case of PDF/X (and PDF/A) compliant files, the Convert to OI feature didn’t actually work the way that customers wanted it to, because it wasn’t actually working as to enable “repurposing” the file to a different press.
In Acrobat X, we recognized these various issues and corrected Convert Colors to OutputIntent to work as customers expected, which is that it now enables you to take a PDF/X (or PDF/A) compliant file with an embedded OutputIntent and repurpose that file (according to the relevant standards) for use on a different device. Color conversion itself continues to be handled by the Conversion commands as it always has, with the various Convert Options (preserve black, etc.) working as they should. ADDITIONALLY, as you have noted, we are now able to provide the ADDITIONAL feature of applying the OutputIntent to a file that doesn’t already have one. However, that’s not really all that useful since Acrobat will ignore an OutputIntent in a file that doesn’t comply with PDF/X or PDF/A.
Does this help you understand our position? Do you now agree that Acrobat is behaving correctly and there is nothing to be fixed?
If you have a PDF that when converted using the standard Conversion Commands (and associated Convert Options) does not convert as you expect with Acrobat X, I would very much like to see it so that we can fix any bugs in the actual conversion. Please post or email me copies of any such PDFs along with explanations of which object(s) I should be looking at.
Yes, Now I see where the broken functionality of Acrobat 9 was throwing me off. I was thinking that the preserve black option did not apply to the standard conversion commands but instead only to the convert to output intent function.
I now understand why I was so confused by the fix in Acrobat X, and that the conversions I want to perform can be done with the standard conversion commands while preserving black.
After multiple tests today I can see that the preserve black function in fact does work when using the standard conversion commands as you say. In fact I have already seen that I can achieve the workflow desired by using the standard conversion commands while preserving black and then I can use the convert to output intent to embed the correctly matching output intent profile if desired.
I am also seeing that using the standard conversion commands for this will be an advantage since I can customize using differing rendering intents when needed.
I will need to test and set up a bit of pre-processing to take care of Spot and NChannel colors that do not seem to convert to the selected destination, but I can work with that.
Excellent! I cannot tell you how excited I am to finally wrap my brain around this issue properly, and I am so sorry it took so much effort to set me straight on this.
Thank you very much for your help.
Thanks for the excellent explanation Mr. lrosenth of the difference between Acrobat 9 and Acrobat X. It is now also clear to me. Although for me the old way was easier (I immediately saw what the transfer has changed - now I have to select the correct Output Intent). Pity the Standard Commands Conversion is not possible to transfer the right to choose as Output Intent profile. Then I just saved the file and I should PDF/X1a Output Intent with Multiflag done.
(unless of course, in other respects meets the standard PDF/X1a)
Thanks Irosenth. It is now clear to me. But the conversion options when choosing color Convert to Output Intend (preverse black ...) are confusing.
Do please look at this video: http://screenr.com/BmZ8. To achieve the same result as in Acrobat 9, I have to use two steps. I can not do everything at once.
But mainly, that I understand what you meant. Just as I say, the damage output that can not Intend to assign it as the first step in Version 9 Or write me how.
Thanks a lot.
Yes, setup a preflight with a convert colors fix up. I did this yesterday and it allows you to embed the destination profile as the output intent while converting the color in one step. It does want you to save the PDF immediately when this happens, so you have to perform that as part of the process. The one step operations using this panel are quite nice though.
You may even find that you want to add other operations or checks into this one click operation.
You can also put it into a preflight droplet and drop multiple PDFs at a time, but I will admit that I do not use the droplets without carefully comparing to the original to make sure that nothing is messed up... Paranoia from bad experiences :)
I am actually ready to drop acrobat 9 now and work in X from here forward.
If you want I can show you some screen shots of the preflight I setup yesterday when I get back to work on Thursday.
Gotta start up the Independence Day celebrations now.
Have a good day.
I apologize on the delay in getting you these, but I am out of my office until July 16th and only have access to Acrobat Pro X there.
I will try to send you something when I return.
Until then I recommend exploring the "Preflight Panel" of Acrobat. In the "Fixups" there is a convert colors function that has settings that will allow you to save a preflight that will both convert color and embed the output intent in a single click. The source and destination profiles can be set in this fixup as well as preserving the black and choosing a rendering intent.
I find the Preflight Panel of Acrobat a bit tedious to navigate sometimes, so try to be patient when first finding things. Using the search window in that panel helps a little when you are having trouble finding what you are looking for.
Hallo Dallas, hallo Irosenth,
I just found out that the color conversion in Acrobat XI works exactly the same as in Acrobat 9. That the alleged error, which was, according to Mr. Irosentha fixed in version X, returned ...
That I could once again return to the old color conversion that I fit in Version 9?
Can you please sir Irosenth say whether this behavior so it remains to new colleagues could train this way, or it will change again in version XII?
Thank you very much for your answer.
according to me in version XI again working properly, but very confusing to me your previous explanation for this behavior was removed in version X (as you fixed in version 9)
see your comment No. 19
Acrobat 9 Pro - functional colormanagement - http://screenr.com/3T08
Acrobat Pro X - not functional colormanagement - http://screenr.com/eT08
Acrobat Pro XI - functional colormanagement - http://screenr.com/QVu7
In Acrobat Pro XI I came across a very strange behavior. Please take a look at it sir Irosenth. http://forums.adobe.com/message/5131525#5131525
When I wrote that, there was a misunderstanding of what you and others were actually asking for. During the Acrobat XI development, we re-evaluated the entire color conversion mechanism vs. how things should be working and made sure that it worked as expected. Acrobat XI doesn’t work like 9 or X – there are differences between all of them. We believe that XI is now correct in all cases.
Hello sir Irosenth,
thank you very much for the quick reply.
That behaves differently Acrobat XI I've also found very very confusing to me its special behavior in the Output Preview, see the link that I mentioned above.
Please see this behavior. Now I do not know how in Acrobat XI find out what real CMYK values are in PDF from the client included, unless it is not PDF / X.