Snow Leopard, Epson 2880/3880 and ColorMunki

[neil snape]

Yes and no. It would be wise to open the Tiff in Acrobat and use the production tools, ink, and watch the numbers in rgb to see if indeed they are unaltered.

Problem:

XRite have made the charts hidden in code in the application and not separate files , and not tiffs,

Since SL absolutely has to have a profile attached, or assumed who knows for sure nothing is being converted upon export to PDF?
There is the other idea of cache files holding onto the last print settings used rather than default.

It really sucks that in CM app, there isn't even a orientation button to save a bit of roll paper.  It's one thing to keep it simple , but another thing to miss the boat when it comes to intelligent GUI.

[Doyle Yoder]

Yes and no. It would be wise to open the Tiff in Acrobat and use the production tools, ink, and watch the numbers in rgb to see if indeed they are unaltered.

Problem:

XRite have made the charts hidden in code in the application and not separate files , and not tiffs,

Since SL absolutely has to have a profile attached, or assumed who knows for sure nothing is being converted upon export to PDF?
There is the other idea of cache files holding onto the last print settings used rather than default.

It really sucks that in CM app, there isn't even a orientation button to save a bit of roll paper.  It's one thing to keep it simple , but another thing to miss the boat when it comes to intelligent GUI.

Not a problem if "Save PDF to Folder as Tiff".

I wish people would get this right, only some drivers require a profile to be attached.

I cannot test the Munki but Eye-One Match is not converting when "Save PDF to Folder as Tiff" is used, so since is is a OS thing I am assuming the same happens with ColorMunki.

Doyle

[neil snape]

Not a problem if "Save PDF to Folder as Tiff".

I wish people would get this right, only some drivers require a profile to be attached.

I cannot test the Munki but Eye-One Match is not converting when "Save PDF to Folder as Tiff" is used, so since is is a OS thing I am assuming the same happens with ColorMunki.

Doyle

The drivers have allows had to have a flavour of rgb passed through the driver  if you look in the summary. This has been that way for many versions of OsX. Not sure on Epson drivers how to extract the actual spool file but I do know how on HP.

Tagged profiles, and or embedded  are not an obligation on past versions. Yet it seems that many are saying this is so with SL, in particular with the Epson driver. Eric Chan deduced the easiest way to avoid the problem of conversion and or writing the wrong space into the spool file is to run a nul profile conversion easily done by using the same profile which causes a nul transform. That is the driver level. Which applications are written for SL that send out data and in space is a mystery. HP drivers seem to do the right thing, as well as the X-Rite HP app called APS which is similar to X-Rite i1 Match, and the built in HP profiler which is HP code.

So instead of saying you wish some people would get this right, it should be some developers get this right and their collateral efforts get it right together.

[Doyle Yoder]

So instead of saying you wish some people would get this right, it should be some developers get this right and their collateral efforts get it right together.

I agree, but this problem appears to be specific to drivers not developed properly for SL and applications using Apple's New Printing Path, not Apple or Adobe. With old 3.09 drivers for the Epson 9600 one has to assign sRGB to avoid conversion in the Driver/OS combo. With Canon iPF drivers one can pass untagged RGB files without conversion.

The big question with ColorMunki printing, does it use the old path or the new printing path? Applications using the old path do not have this problem. In my testing without having the hardware, one of the apps in the CM suite used the old path the same as Eye-Match. Which should mean the profile is OK but a conversion takes place in the Driver/OS combo with drivers not written properly for the new printing path. So converting in PS to the CM created profile and then assign what ever profile the Driver/OS combo is using should allow printing correctly.

Of course if ColorMunki is using the new path then all bets are off and back to the printer driver being correct.

So again can somebody answer the simple question, which path is ColorMunki using?

Doyle