Does input profile detection ever work?

[JoshB]

98% of the time this is a moot point, because people usually send us files using SWOP as the output intent, but when that is not the case, I've not found any way to make the RIP use the incoming document's output intent.

The manuals are contradictory, but the ColorPro User's Guide says that:

A PDF/X-3 file containing an OutputIntents dictionary will be color managed using the ICC profile indicated by the OutputIntents dictionary, as long as the job uses a device independent color space and the Override color management in job option is not selected

This, unfortunately, doesn't seem to be true. I found it quite startling that the RIP would not use the incoming document's output intent in all circumstances (though I do understand how a very dogmatic interpretation of the spec could lead to this in the case of x1a), but that it does not seem to follow the documented behavior for X3 is even more frustrating.

I have created an array of test cases, taking the same document and but saving it as plain PDF, x1a, and X3 and I have assigned (not converted) different output intents for each flavor. I've also made sure that "Override color management in job" is not selected, and I've tried all the "PDF options". In each of these cases the output raster is bit for bit identical and corresponds to whatever is set as the default incoming CMYK profile. If "none" is selected as the default, then the output device profile is assumed for the input.'

This is occurring with version 8-3.

[JoshB]

OK. Egg on my face. Not a Harlequin problem at all.

I'm writing good X3s to my debugging stream, but the actual data going through the pipe to the RIP is missing the XML metadata, causing the document to not be interpreted as plain PDF. So the core issue here has nothing to do with the RIP.