Raster or Vector PDF proofing

[Todd Smith]

Which type of PDFs do you use for customer proofs? Raster or Vector? Why? I say Raster, but need good arguments for Rastor.

 

[HafProp]

I use whatever the customer supplies. I do not see any reason to rasterize proofs before sending.
If you're worried about the file becoming corrupt, Zip it then send it.

 

[prepressdork]

What HafProp said. Most PDF proofs I send contain a mixture of vector and raster content.

 

[chromacharles]

RAMPAGE used to generate raster files. I liked that since we had that set up as a ROOM. Now we are in XMF in a NORM which I personally don't like but it works LOL

 

[Joe]

Vector is better looking and smaller files. But if a customer decides to open it with XYZ pdf viewer it may not look right if XYZ doesn't support transparency and later PDF content. And even sometimes they won't be looking at what will actually print even if they use Adobe Acrobat Reader and they don't have overprint preview enabled. We ran into that about a week ago. The only way to make sure the customer is viewing what it will print like is via a raster file...assuming the path to raster isn't changing something. In prepress there is always the possibility to lose no matter what you do.

 

[OffsetStorefront]

Yeah, we've had font issues come up on the RIPed file but not the vector file. We proofed a regular vector PDF then RIPed it and messed up the job. So if you want to be super particular and careful about it, RIP the file in the RIP that's going to print the piece, get it back out of the RIP (if it lets you, some don't), then send it as a proof.

An online proof viewer is a good way to get around both not knowing how the customer will view your proof and avoiding sending large RIPed PDFs. But you need some supporting software to do all that.

 

[Jim Restle]

Vector is better looking and smaller files. But if a customer decides to open it with XYZ pdf viewer it may not look right if XYZ doesn't support transparency and later PDF content. And even sometimes they won't be looking at what will actually print even if they use Adobe Acrobat Reader and they don't have overprint preview enabled. We ran into that about a week ago. The only way to make sure the customer is viewing what it will print like is via a raster file...assuming the path to raster isn't changing something. In prepress there is always the possibility to lose no matter what you do.

Pretty much what Joe said.

 

[chriscozi]

We use Raster.
See the recent (last year) change by Adobe to ALLOW TRANSPARENT WHITE RGB objects.
These preview fine in screen preview (Overprint Off - the DEFAULT setting)
BUT THEY DISAPPEAR UPON RASTERIZATION.

So even if all the other features suggest vector, we are loathe to leave the Raster proof.

 

[Magnus59]

We avoid PDFs as proofs whenever possible, any time a CSR asks for a "PDF Proof" I tell them "PDFS are NOT proofs"
I keep a couple of sample PDFs on my desktop to demonstrate the issues with viewing PDFs in different environments
Clicking on and off the Simulate Overprint button shows the problems.
We use a proofing solution that passes the refined files through the RIP and displays them as RIPped pages, if a customer requests a soft proof we strongly encourage them to use this instead of PDFs

 

[PeteKincaid]

Many good points above. I believe in today's world a raster-based soft proofing solution is the best answer. What this means is a PDF is given to a soft proofing solution, the file is "ripped" to raster and those raster tiles are streamed via a web browser to your end-user.

The benefits include:
File size doesn't matter (Pixel on-demand streaming technology)
Transparencies are no longer an issue
Customers don't need any special software, only a web browser
You can automate the process of either a single approval or a complex multi stage approval.
Annotation capabilities