FWIW. A few thoughts:
(1) If you are a print service provider providing a “proof” to a customer in PDF form, it really should be a raster PDF file coming directly from the same RIP used for printing. Each page should be a single ZIP-compressed (to avoid compression artifacts that accompany JPEG compression) CMYK (+ spot channels if appropriate) raster image at device resolution. Either each image needs to be tagged with a CMYK ICC profile or the file should be a PDF/X-4 file with an output intent matching the CMYK printing condition. Otherwise, what you have is anything but a real digital proof but more like a restatement of the PDF originally provided.
(2) Viewing such a PDF file requires a viewer that properly converts such raster images from the designated CMYK color space (per above) to the RGB color space of the monitor. Such conversions are not possible with MacOS or iOS Preview, Google's PDF viewer, or Microsoft's Edge browser's PDF viewer. Adobe Acrobat, Adobe Reader, and other real PDF products do support such proper viewing.
(3) And of course, if a customer is relying on soft proofing, their monitors should be calibrated.
If the above conditions are not in place, both the print service provider and the customers are simply fooling themselves.
Right. We have a Versafire with its own rip as well as some Agfa machines with their own rips as well. I've been told that most rips can be configured to simply be a passthrough that gets the file to the machine. I'm hoping that I can set ours up this way at some point so that the only rip being used is the one we softproof out of.Technically soft proofing AFTER ripping would be the safest way to go, because you're right in that things can happen during the RIP process, but I know that for our digital presses with a Fiery RIP and Command Workstation, it doesn't give you access to the ripped PDF to send out, so we're stuck with proofing pre-ripped PDFs.
Exactly! My thoughts as well.Softproof has to be done after converting the to pdf, for whatever workflow you are using - otherwise you are not proving anything! They are called proofs because they prove the file to be correct! IMHO
We soft proof our digital press files through our Heidelberg system - same work flow as offset
Thank you for this! I will take a look. The idea of the proof PDF being a raster PDF is interesting. I haven't heard of doing this before.... I interpret this to mean that everything in the document is rasterized. Or does it simply speak to the changes that happen to the file once its gone through the raster image processor?If you do search on this forum, you will find Dov's post, which I like a lot and use as a bible. You have to process PDF through Rip/Renderer and softproof rasterized, color managed data, otherwise you are fooling both yourself and customer.
Color is in demand in all types of documents, making color management a critical part of Digital Printing 5.0. Managing color on one device/press can be an easy task with the correct tools and processes. But managing color to ensure printed pages are consistent and repeatable across the different substrates and color gamuts of toner and inkjet can be a much bigger challenge. Properly implemented color management workflows can help achieve consistent color results across multiple devices. Although many end-customers are claiming satisfaction with “pleasing color,” two challenges are still in play. Link to Article