Proofing service providers are often asked the question: “I have to have a proof done, but I don’t know for which profile. Can I also have a proof made without a profile?”
Proofs are standardized products that are created and tested according to a certain set of values. This is exactly the point that distinguishes them from any “colourful printouts”.
Specifically: A proof for coated printing paper is produced according to the standard values of ISOCoated V2 (paper type 1 and 2, glossy and matt coated image printing, dot gain curves A (CMY) and B (K) from ISO 12647-2:2004) and checked according to a set of values (FOGRA39L). A proof for uncoated paper (e.g. PSOUncoated or ISOUncoated) is produced and checked according to completely different value sets. Logically, because a print on uncoated paper looks definitely different in terms of colour and white value than a print on picture printing paper.
A proof must therefore always be prepared according to a standard and be verifiable according to a reference value set. A list of the current Proof Profiles (as of 2012) can be found here.
The problem: Many printing processes such as digital printing on a color laser or printing on a large format printing system (LFP) are not standardized and therefore there are no valid profiles and specifications.
So what to do? The most frequently used standard has established itself as the “de facto basis”: ISOCoated V2.
This is understandable, because colour-critical prints, catalogues etc. are mainly produced in offset printing on picture printing paper and are therefore subject to this standard. It is therefore generally assumed that a digital printer or an LFP printer, for example, should follow this standard and at least achieve this colour result.
So if you need to make a proof but don’t have the exact details of the profile you need, proof ISOCoated V2, which has become the industry’s most widely used standard and will always be accepted as the basic proof.
Unfortunately, a proof without a profile cannot be produced, because that would just be “colored paper from a proofing system”, but not a valid, ISO-compliant proof.
A few days ago we received a call from a customer in the field of design, who sent open Adobe InDesign data in ISOCoatedV2 300% with contained RGB images to the production company for a complex CD production on the advice of the producing company (“The printing company still has a prepress stage, which can then prepare your data optimally…”). The result of the finished printed CD booklets and inlays did not correspond at all to the calibrated monitor image of our customer, the client was also unhappy and requested the print data about the production company from the print shop responsible for the print to troubleshoot. Data in the “US Web Coated” color space with 350% ink coverage came back from the printer. For troubleshooting, the customer then had a proof of his data created by us, but had chosen the settings “Convert to target profile (retain values)” as usual when writing the proof PDF; we thus received completely CMYK data, of which we produced a proof according to ISOCoatedV2 300%, which completely met our customer’s expectations. So it seems that the designer created the data correctly and printed the print shop incorrectly.
On closer inspection, our error analysis revealed two serious weaknesses:
In this case, a complaint of the designer to the printing company will of course be difficult, as on the one hand, non-profiled RGB data were sent to the production company, and on the other hand, no print PDF generated by the data creator in the correct output color space ISOCoatedV2 300% was supplied.
If this had been done, one could at least have argued that the expected color of the production print would have been comprehensively known. Thus, one can only refer to the fact that the printer would have had to ask the designer for RGB data without an embedded color profile, and should not have assigned the data somehow to a profile “blindly”. The fact that the print shop with its crude US Web Coated workflow certainly did not create a correct print file, but a wrong one for the output, can indeed be stated, but the print shop can always talk its way out to “systems with in-house standard”.
If we receive a PDF file that contains RGB images, the next step is to check if the file is a valid PDF/X-3 or PDF/X-4. If this is the case, we check whether all input RGB profiles are correctly marked with color space (sRGB / AdobeRGB / ECI-RGB-V2 etc.) and rendering intent, then we check whether the correct output color space was used as output intent and whether also contained CMYK data have the correct input profiles. If yes, then we proof the file with the settings: “Consider all input and output color spaces”.
In this case, the file is reproduced 100% exactly as our customer created and defined the color profiles. If he has made a mistake and e.g. marked an image with a wrong RGB profile, this will also be “incorrectly proofed” exactly as correctly.
If RGB data should not contain a profile, e.g. if they are created in Device RGB, we generate a “data incorrect” e-mail in which we explain our procedure as follows:
“Dear customer, the data check has shown that RGB elements are contained in your data. RGB elements can only be safely interpreted in the proof if they are marked with a color profile and a rendering intent. This is the case, for example, with correct PDF/X-3 and PDF/X-4 data. The correct output intent must also be specified.
At least one of these criteria does not seem to be the case for your file. The safest way would be to convert the contained RGB data to CMYK. This has the advantage that you have control over the conversion and can view the CMYK result again in Acrobat before uploading the file again for proofing. We can then reliably use your CMYK values for the proof. To do this, call up the current order in your customer account, delete the incorrect data and upload the corrected data.
If, for example, the RGB element should only be a small image that is not relevant for the overall impression of the proof, or if you do not have another file available for the proof, then of course we can also use your RGB data for the proof. If available, we use your RGB source profiles and rendering intents, otherwise we use the sRGB standard and the rendering intent “relatively colorimetric with depth compensation”, which in most cases will lead to correct proof results. If you would like us to proof the supplied RGB data in this way, please let us know. Please do not hesitate to contact us if you have any questions. Best regards, your proofing team”.
In our case, the CD production case would also not have occurred in the proof, as we reject RGB data not provided with an ICC profile with the error message mentioned above, and do not convert them, as we cannot predict precisely how our customer would have liked the data to be converted.
We are aware that our approach is not 100% the ultimate best approach in all cases, but to the best of our knowledge and belief it is best in line with market practice and the expectations of our customers.
However, we are also happy to accept your individual requirements and circumstances. Give us a call or send us an email and describe your processing requirements.
By the way: We are happy to put our knowledge and data competence at your service: If you also have a problem, a question about print data, data preparation, or – as in the above example – a misprint has already occurred and you need external expertise and assistance for the complaint: Give us a call. We will be happy to advise you and help you where we can help. We will charge you for our advice and analysis at an hourly rate of EUR 90,- plus VAT, and you will be billed for 15 minutes each. An initial consultation and assessment is of course free of charge.