When we receive a file from you, we first check whether it contains any colours other than CMYK. If the file consists exclusively of CMYK, it is sent directly for proofing.
Handling of incorrect profiles in CMYK data / "profile mismatch"
If we receive exclusively CMYK data from you, we ignore all embedded input and output profiles and only use the CMYK values, which we bring to the ordered output colour space.
Example 1: Data in ISOCoated, proof in ISOCoatedV2 ordered, so incorrect or no CMYK profile embedded
You send a file with the ISOCoated profile and a colour area in CMYK 100/70/0/0 and order a proof according to ISOCoatedV2. We ignore the ISOCoated profile and proof the pure colour value 100/70/0/0 according to ISOCoatedV2.
Why do we do this? We try to reproduce the "lived reality" of printing in our proofs as well as possible. In many conversations with print shops, we have seen that they perform CMYK to CMYK profile conversions in almost 100% of cases, but instead bring a colour value of 100/70/0/0 to the plate without regard to CMYK profiles, insert paper and print according to the standard. We therefore also map this path, even though it would actually be "more correct" to perform a colour space transfer from ISOCoated 100/70/0/0 to ISOCoatedV2. However, this results in a different colour value, for example with relatively colourimetric conversion with depth compensation 100/63/1/6 or perceptually with depth compensation 100/63/3/15!
Practical case: A customer of ours did not proof with us but with a colleague proofing 30 slightly different dark blue colour areas in ISOCoatedV2, under each of which the CMYK value was printed in black lettering to match a powder-coated surface in terms of colour. Based on the proofed colour areas, the customer defined a very good matching CMYK colour value, inserted it into his brochures and started the print jobs.
Result: The dark blue was a distinctly different blue each time than on the reference proof, the customer and agency were very dissatisfied and went looking for errors.
Now the case came to us. We received a file for proofing according to ISOCoatedV2 and compared it with our colleague's proof. The colours with the same black CMYK values printed below them were distinctly different, both proofs with media wedge and correctly measured. After some troubleshooting, we got the idea of requesting the file originally proofed by our colleague, which still existed. We found a Fogra27Coated profile in it, an implementation of the old ISOCoated. A proof according to ISOCoatedV2 had been ordered at the time.
What had happened? Our colleague had considered the input profiles, which resulted in a significant change in the CMYK values of the colour areas due to a colour space transfer from CMYK to CMYK as described above. Of course, the black printed CMYK values below the colour areas did not change. The matched CMYK value therefore did not correspond to the proofed value at all. Our customer was shocked: "What, our CMYK values weren't proofed?".
With us, this case would not have occurred because we would ignore the embedded profile in CMYK data. This would also have been the expected behaviour of our customer. After almost two hours, we had identified the "error" (or perhaps rather the "difference"), created an "expected" proof for our customer, using which he could determine the correct CMYK value in ISOCoatedV2, and we had resolved the problem.