So you're saying the PS level 3 does not support ICC color management?
As defined by the PS Level 3 standard, there is no such thing as ICC color management.
Are there RIPs (and other tools) that EXTEND the standard to do so - of course. It's been part of Adobe CPSI for years. But supporting something and having it be part of the standard are two different things.
I agree but clearly you don't get out much, it's done everywhere,
People do lots of things that aren't good for themselves - smoking, not wearing seat belts, jumping of bridges, etc.
Doesn't make it right and it CERTAINLY isn't something that I would promote, especially in a public forum.
Because may RIPS and therefore print companies do not accept PDF files that are not Distiller published,
I've NEVER seen a RIP that has any such restriction - since the RIP doesn't bother looking at that. I have, however, heard of some antiquated print vendors with such restrictions but I was pretty sure most of them had died out. These days, everyone seems to be (as they should) requesting PDF/X (usually -1a) files - in which case the producer doesn't matter.
Distiller is a product whose time has come and gone. Move on...
Many people do not use Adobe applications, so they print to the PDF printer and Distill.
True, though many other applications have native PDF support these days as well. MSOffice, OpenOffice, Corel, iWork, etc. So even there it isn't necessary.
And those that have to print to the PDF printer - sure. How that particular printer driver happens to work shouldn't matter. Today, on Windows, it happens to use Postscript and Distiller, but there may come a day that such things change - just as we had to on Mac OS X.
I can understand that you may not buy much printing?
I don't, but my wife does. She sends either PDF/X-4 or PDF/X-1a to her printers and has never had a problem.
Ok sure PS level 3 has remained stagnent and PDF has since evolved. So I'll give you a choice, when I was writing pre-press articles for Cygnus years ago and PDF was new, Adobe said it was a subset of PS. Which one of you was telling the truth? You or the guy way back then?
Depends
.
Postscript is a full fledged programming language, offering loops, variables, conditionals, etc that also happens to support a Page Description Language (PDL). PDF is a structured binary file format for containing a PDL. So if you look at it that way, since PDF only does the PDL bits of Postscript, you could argue that it's a subset.
BUT the imaging model itself has always been equal or greater than Postscript. (the only exception being the very short time between the release of PS Level 2 and PDF 1.2 and then PS Level 3 and PDF 1.3).
Publically supported is NOT ICC compliant, IMO this is Adobe making it's own rules.
ICC compliant means that it follows the rules defined by the ICC. So if the ICC is defining BlackPoint Compensation and it's use, therefore such use is compliant. I agree, however, that the current ICC Profile specification says nothing about BPC, and the ICC is working on an update that will correct that.
No what I mean is that a spot color in Indesign will convert to a different CMYK value then it's suppossed to.
A spot color added natively in InDesign or imported with artwork? Converted WHEN?
As I mentioned in an earlier message, there are a number of possible options here, depending on the conditions. I need to know your EXACT workflow to be able to comment...
Ok try this take a control RGB image, convert it to 2 different CMYK color spaces, one that matches the cmyk setting in InDesign and one that does not, make sure to embedd the profiles in the tiffs and have the apps color setting set to honor profiles. Now I'm on vacation working with CS5 so this is not CS6, the one that matches the apps space displays fine the other shifts and there's nothing you can do about it. Same thing happens for all color spaces.
I would never pre-convert RGB to CMYK. Throwing away useful information (eg. color gamut in this case) makes no sense. But for this example, I'll play along.
I don't see the problem with this workflow - that is EXACTLY what I would expect.
I have an image with embedded profile (let's say SWOP) and I place it into a document whose working colorspace is a different profile (eg. ISO Coated). In order to render the image in the document's working space, it has to convert from the one profile into the other profile. It does so using standard ICC color management, which in this case would be a 4->3->4 conversion from SWOP->PCS->ISO Coated. Which will almost always result in a color shift and why most creatives would tell you NEVER to do that.
The recommend method is, as I mentioned earlier, keep the images in some RGB (with embedded profile) and place them as is into InDesign, regardless of working space. They will happily convert for rendering without the color shifts (since you have the wider gamut to work with) and when you export to PDF at the end, you can then control the final Output Profile (hopefully as part of a PDF/X conversion).