I got a pdf proof that the preview is jacked up can I trust it the image file?

[texnartist]

I got a pdf proof that the PDF preview is jacked up can I trust it the image file? Once I open it, it appears fine. Talk about freaking out my client.

Can anyone help?

From the publication the preview:

The publication's file opened.

The file I submitted.

[Dov Isaacs]

If you are willing to post the actual PDF file, maybe we can see what's going on here. Otherwise, nothing stands out to comment on!

          - Dov

[texnartist]

Link to the pdf that has the jacked up preview. Thanks for your help.

https://drive.google.com/file/d/0B0cUzIIw0d_QVnF1QXJlUUhpZVk/view?usp=sharing

[Dov Isaacs]

OK. Downloaded and examined it.

Running all relevant tools in Acrobat Preflight, there doesn't appear to be any reason why you would or should get the results returned to you as a “preview.” I also tried printing this directly from Acrobat Pro DC and the output was exactly as expected.

Examining the file further:

What appears to be going on is that whatever is producing that “preview” (presumably some PDF workflow or RIP software) is misinterpreting the boundaries of the central image of this page, the green background with the cellphones and text "WILL-CALL OR DELIVERY WHEN YOU NEED IT". More specifically, it is improperly clipping the edges of the image.

There are some anomalies in the file such as:

(1)     Non-embedded Helvetica fonts (used in document info outside of printed area).

(2)     For some unknown reason, the image is needlessly set as being part of an isolated non-knockout transparency group. This is totally unnecessary to achieve the desired visual effects.

(3)     The image is fairly low resolution, 150 pixels/inch, a bit low for high quality offset printing.

(4)     The crop marks you showed in your figure aren't in the file and there are no crop boxes defined in the PDF file. Is this the PDF file you submitted or something they derived from it? If the former, how was it created? It wasn't Illustrator or InDesign since the PDF information shows that it was generated by something called PDF PT 4.10 (pdf-tools.com). Normally, PDF files submitted for publication use PDF/X and given that you have transparency, PDF/X-4 would have been appropriate. This is not a PDF/X file.

However, none of these three issues should cause the visual anomaly presented to you.

The question is exactly what is this publication using to produce this preview? I'm assume they are placing the PDF file into a layout program? I tried placing this PDF file into an InDesign document and encountered no problems other than (4) above due to the lack of crop box settings.

          - Dov

[texnartist]

Thank you for reviewing that. I double checked the image source from photoshop is 300 dpi cmyk and place into indesign and output as a press quality pdf.

Here is the original file I submitted to the publication.

https://drive.google.com/file/d/0B0cUzIIw0d_QQkVhRElEcnJtZnM/view?usp=sharing

From what I gathered, it is a problem with Naylor's RIP.

Cody

[Dov Isaacs · Accepted solution]

Your original PDF file looks fine. It has an extraneous page level transparency group, but that should have not made one iota of difference.

Assuming that they are placing your ad in a publication, they shouldn't be mucking with it as they are. It is amazing how many publications and print service providers feel compelled to muck up perfectly fine submitted PDF files with unnecessary, crappy, “added value” PDF workflow products that often cause much more damage than any benefits allegedly offered.

Sorry to see you suffering with this publication. Good luck!

          - Dov

[texnartist]

thank you.

[Luke Jennings]

Your original submitted file is fine, although I would increase the crop mark offset to .125"

The PDF proof they returned is also fine, except the dimensions are much smaller than the submitted file, I don't know if this is intentional.

Your client needs to be informed Preview is not a suitable application for reviewing PDF proofs. Acrobat or Adobe Reader should be used, with the overprint preview option set to always on.

As for your print service "mucking up" your file, they are responsible for printing your work that will match the PDF proof, The printer must process your file, often as part of an automated workflow, which may include a number of checks and fixes, correcting issues that  might not appear on screen, but could appear on the printed piece.

[Dov Isaacs]

In no place did the OP mention use of MacOS “Preview” but rather, referred to a preview image file (the first of the three images in the initial posting), not a PDF file. If that preview image file was meant to represent what the publication was actually going to use, there is a really big problem. Again, the publication is mucking around with what was a perfectly fine PDF file that could / should be placed as-is!

And yes, normally a bleed area should be larger, but if this ad was anything but a full page ad (we don't know), then bleed becomes totally irrelevant.

          - Dov

[Luke Jennings]

Preview the application and preview the verb are often confused, in my experience, in addition, the "jacked up" PDF looks exactly like the first screen shot, when displayed in Mac Preview (and probably other viewers) but looks fine in Acrobat.  I'm jumping to the assumption that his client used Preview to check the PDF proof and complained "the preview is jacked up!"

Using Preview or some other inadequate PDF viewer is the number one cause of PDF proof complaints, not using overprint preview in Acrobat is probably 2nd.

If the PDF proof is at the correct size, then there is nothing at all wrong with it and the client can relax (after downloading Reader).

[Dov Isaacs]

I honestly don't know what we can assume. For all we know, the publication may have created a TIFF file from MacOS Preview and sent it to the customer.

Regardless, I think we can safely say that we are in violent agreement that MacOS is not a proper PDF viewer in that it doesn't even begin to fully and properly implement the PDF specification!

The problem of course is that no matter what you or I say, there is a very large number of Mac users including some who get involved in PDF workflows who still believe that Apple is infallible and that if content doesn't look right in Preview, it must be the fault of non-Apple component that created that content.

          - Dov