Softproofing Before OR After Ripping

[ChrisWorks]

Someone I spoke with recently mentioned that they softproof files BEFORE they are Ripped. I've always heard that soft proofing should always be done AFTER Ripping in case the rip creates an issue with the file. What are your thoughts? What's your workflow for softproofing?

 

[OffsetStorefront]

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.

 

[akalaray]

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

 

[zoran]

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.
https://printplanet.com/forum/prepr...f-reader-for-dumb-clients?p=276149#post276149

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.

- Dov

 

[ChrisWorks]

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.

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.

 

[ChrisWorks]

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

Exactly! My thoughts as well.

 

[ChrisWorks]

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.
https://printplanet.com/forum/prepr...f-reader-for-dumb-clients?p=276149#post276149

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?

 

[zoran]

In modern workflow with Renderer, entire file would be rasterized using same Renderer that outputs your proofs/plates.

 

[michaelejahn]

I appreciate everyone being super careful - and while some workflows and business relationships actually require a signed off proof ( where the proof is a more or less a 'business contract' )

- in a world where customers use storefront templates for digital printing, soft proofing is all that ever happens in the overwhelming majority of the time.

Most Print MIS systems off things like this:

https://acme.presswise.com/account/status.php?webID=Y2MyYTNkMjRhM2Yx

 

[Magnus59]

Any soft proof must be post-rip, a PDF that hasn't been rendered means nothing. I've spent years trying to explain this to CSRs, but they would still prefer to blame Prepress when something goes wrong rather than listening to us.
I just had a job today from our internal designer, the CSR had sent a PDF from the designer to the customer and then told me I could proceed to plate without a proof because the customer had approved the PDF.
Of course I refused and told CSR that I would be printing a proof whether he liked it or not. Designer had placed a white box over a CMYK blend and set the white box to x% transparency. The RIP produced this as a white box, 16 plates and probably the job saved.
We use Kodak Insite for soft proofing which renders the proofs using the same RIP that is used for final output, but the designer and the CSRs see this as a "Prepress thing" rather than a whole of organisation tool so it doesn't yield the benefits it could do if everybody used it fully.

 

[ChrisWorks]

Any soft proof must be post-rip, a PDF that hasn't been rendered means nothing. I've spent years trying to explain this to CSRs, but they would still prefer to blame Prepress when something goes wrong rather than listening to us.
I just had a job today from our internal designer, the CSR had sent a PDF from the designer to the customer and then told me I could proceed to plate without a proof because the customer had approved the PDF.
Of course I refused and told CSR that I would be printing a proof whether he liked it or not. Designer had placed a white box over a CMYK blend and set the white box to x% transparency. The RIP produced this as a white box, 16 plates and probably the job saved.
We use Kodak Insite for soft proofing which renders the proofs using the same RIP that is used for final output, but the designer and the CSRs see this as a "Prepress thing" rather than a whole of organisation tool so it doesn't yield the benefits it could do if everybody used it fully.

Totally with you on this. And this is how I've always been taught. Every print company I've worked at has had the same issue with some CSRs & Sales being at odds with Prepress and not willing to learn the process. We were even using InSite but despite pushing to use it, couldn't get everyone on board with it, so we ultimately abandoned it.