• Best Wishes to all for a Wonderful, Joyous & Beautiful Holiday Season, and a Joyful New Year!

Preflight and fix large volume pdf's - Books Digital - print

nikleon71

Active member
Hi , i am searching for a preflight set that anlyzes and fix pdf files that going for digital printing 4 colour Coated and uncoated papers , which one you suggest? do i have to fix manually one? which are the criteria i have to take in account? Acrobat is safe to fix as the pdf's are large volume pages more than 600 pages sometimes i need something very safe to rely on and fix all the minor mistakes.
 
And exactly what do you mean by “minor mistakes?”

What problems are you encountering?

In most cases that I have seen, problems with printing have to do with how the PDF files are created in the first place (failure to specify that fonts must be embedded or specification of improper image parameters such as downsampling to low resolution or use of low quality JPEG) or how the content is composed in the layout program (such as InDesign, Illustrator, Quark, etc.). Such problems are not necessarily going to be either found or more importantly corrected by a generic preflight profile. This goes under GIGO – Garbage In, Garbage Out.
 
i ment if the file has low resolution - rgb images , very small letters or thin lines, 100% rich black, actually i am searching for a workflow that will ensure me files will be printed without any changes after rip , used to wotk with a Harlequin workflow and i was extremely happy after updating to version 12. thanks for your answer
 
RGB images themselves are not necessarily an issue. Modern RIPs/DFEs properly convert ICC color profile-tagged RGB images to whatever the CMYK color space is. Low resolution images (other than images that of necessity are relatively low resolution, such as screen shots) cannot be “fixed” by a preflight profile - although such profiles can find them in your PDF file.

In terms of “very small letters,” fixing text that was laid out using too small of a point size can't be fixed in a preflight profile, only detected. You need to go back to the authoring program to fix that type (pun intended) of problem.

There are some preflight profiles out there to detect and “fatten” lines below a width per your specification. However, depending upon the original artwork, in some cases it is appropriate to let those lines fade away as opposed to artificially fattening them. For example, if one has a vector diagram that has a large number of lines, some very narrow and others more visible, artificially fattening the thin lines may yield output that really looks obnoxious.

Simply stated, there is no magic cure-all preflight profile to magically make all PDF output look good. Many if not most of the issues go back to the design of the content and the parameters used to create the PDF file.

Personally, I apply two techniques to quickly establish whether a PDF file that I receive can be printed reasonably without going back to the creator of same. The first is to open the PDF file in Acrobat Pro on a large (30" or so) high resolution monitor and if that looks OK, secondly I print one copy to a PostScript printer. Yes, this takes a few minutes, but I find that it finds problems more rapidly and successfully than any preflight profile by itself!
 
And what if the pdf files is complicated with layer or transparensies, there is no way to print or visula check as the number of pages can exceed 500 some times
 
Layers and/or use of transparency are not necessarily problems! If the original content uses transparency, the best practice is to leave the transparency “live” in the PDF file.

The problem is what you are exactly looking for as a “problem” – layers, transparency, etc. are not necessarily a problem if the original content is properly created. Having a preflight profile point out use of transparency or layers by itself tells you absolutely nothing as to whether the job will properly print.

What specific issues do you actually encounter with PDF files and digital printers? What RIP(s), what printers? Do you have a sample (i.e., a PDF file) that exhibits the problems you see?
 
Last edited:
You say “Acrobat is safe to fix”, then why would Acrobat not be sufficient and what additional functionality is it you’re looking for? Automated/batch processing for large amount of files? As Dov indicated traditional preflight/artwork processing have no fix for low resolution images, but there are AI-based image up scaling technologies available these days.
 
With regards to “low resolution images,” one must be very careful in terms of what one does for “low resolution images.”

(1) Some “low resolution images” such as screen shots are inherently low resolution. They match the resolution of the screen from which they are taken. Attempts to “uprez” such images may yield a real visual mess with ugly artifacts, not something that is inherently higher quality.

(2) Having used tools in Photoshop to increase image resolution, it is very clear to me that there is no single setting that is correct for all images (and of course, not all images with resolution below some “magic” value, such as 300dpi should have artificial image resolution enhancement). As such, each image that might be a candidate for such treatment needs to be examined individually with settings appropriate to the particular image and its contents!

(3) Given (1) and (2) above, my original recommendation in terms of visually reviewing the entire PDF file on a large, high resolution, color-calibrated monitor (Windows or Mac, it doesn't matter ;)) and producing a single laser printer copy (PostScript printer) still stands.
 
(3) Given (1) and (2) above, my original recommendation in terms of visually reviewing the entire PDF file on a large, high resolution, color-calibrated monitor (Windows or Mac, it doesn't matter ;)) and producing a single laser printer copy (PostScript printer) still stands.
And I will 'assume' the cost consequences defeat the original poster's business model.
Someday - maybe sooner than we think - it will all fix itself and we won't need those pesky print shops any more.
 
This whole thread reminds me of a phone call I received over 15 years ago from a well-known writer in the print industry press. She wanted to know the technique I recommended for proper “sharpening” of images for print.

My response — “properly focus the camera!”
 
THis i Preflight sample of a pdf with 496 pages, almost everything red, the print os might pass. I was asking if you know anything about a pdf rip solution that deals extremely well with this kind of problems to create datalock files before i impose it and print it.

1726081539412.png
 
Last edited:
Some observations:

(1) The preflight profile you are using is for testing the validity of PDF/X-1a files. Unless you specified that your client provide you with a PDF/X-1a file, this profile is not of much help.

(2) Unless you are using a RIP/DFE that is over 15 years old, PDF/X-1a is really an obsolete standard and workflow based on PDF 1.3 with no ICC color management, no support for anything other than device dependent CMYK plus spot colors, no support for live transparency, etc. Reliable 21st century PDF print publishing workflows should be using PDF/X-4 (based on PDF 1.6) providing support for live transparency and ICC color management (especially ICC-color managed RGB).

(3) The diagnostics under Page Description Errors (errors in PDF syntax, missing extended graphic state, and missing XObjects) are exceptionally problematic. What application and workflow produced this PDF file in the first place? This is certainly not PDF directly out of any standard layout or graphic arts program.

What you presented is clearly more than an issue of finding and using “a preflight set that analyzes and fix pdf files that going for digital printing” – the page description errors noted above cannot be readily “fixed” by simply applying a preflight profile.
 
Thank you for you answer, so its better to ask PDF/X-4 (based on PDF 1.6) pdf files from Costumers.
Where i can learn these major issues about pdf structure? i dont want to learn through mistakes, my general approach for years now was to Ouline fonts through flatener preview if i had font issues enlarge a page in Preps to create bleed , global graphics Rip was ripping everything and i was using low res for impostion which was fine felt safe cause i could check the final ripped page version . Now in new job is tottaly differnet i have to deal with pdf before rip i dont have tools only Acrobat (there is a callas tool i can use and enfocus but not in my system) , its difficult to ask new files for client, so what approach you suggest me to deal all those problems in the digital demaning web workflow.
 
If your customers use PDF/X-4 export settings from popular applications, you shouldn't be seeing any PDF structure errors at all if you are to run the PDF file through a PDF preflight verification of PDF/X-4.

You should never “outline fonts” – that technique was appropriate 20 years ago with dodgy CloneScript RIPs and/or with content created using oddball, improperly-created amateur-hour fonts. If you can properly view a PDF file in Acrobat, you should not have any issues rendering text for printing.

And with current era PDF-based RIPs/DFEs, there really no good reason to either pre-flatten content (either in the application or in Acrobat) or to need to use a flattener preview.
 
If your customers use PDF/X-4 export settings from popular applications, you shouldn't be seeing any PDF structure errors at all if you are to run the PDF file through a PDF preflight verification of PDF/X-4.

You should never “outline fonts” – that technique was appropriate 20 years ago with dodgy CloneScript RIPs and/or with content created using oddball, improperly-created amateur-hour fonts. If you can properly view a PDF file in Acrobat, you should not have any issues rendering text for printing.

And with current era PDF-based RIPs/DFEs, there really no good reason to either pre-flatten content (either in the application or in Acrobat) or to need to use a flattener preview.
Hi Dov -
Thanks for all your comments here!
Technical question about submitted PDF files with embedded Type1 fonts - possibly in old graphics.
Note - these files are coming from non-savvy customers with older machines/software and almost ALWAYS involve one of the standard 23? fonts.

When the files are being processed we see missing font errors, but they rip fine (VISUALLY) as the fonts get replaced at the rip which ALSO have the resident same named open type / true type font.

Soliciting your thoughts about what can/should be done.
Example: "Requiring a PDF/X-4 file will fix the issue"

TIA.
 
Remember that “font” is a four letter word beginning with an F. ;)

One of the biggest mistakes made by the original Adobe Acrobat team was to allow for font usage by reference only, i.e. not embedding all fonts used in a PDF file's text. Part of that decision was the assumption that at least the Base 14 fonts would always be available for use in rendering on the screen and on printers (either as operating system fonts or printer resident fonts). In fact, in early versions of Acrobat (and Acrobat Reader), those Base 14 fonts were bundled with Acrobat and Reader! (These were four faces of Helvetica, four faces of Times, four faces of Courier, Symbol, and ITC Zapf Dingbats.) Those fonts were always available as printer-resident fonts in Postscript Level 2 and PostScript Language Level 3 devices.

Later on, Adobe stopped bundling Helvetica and Times with Acrobat and Reader due to significant licensing cost increases from Monotype (which had acquired the Linotype type libraries). The assumption was that for non-critical work, the Monotype Arial and Times New Roman fonts bundled with Windows and MacOS were “good enough” to mimic Linotype Helvetica and Times – the “advance widths” were the same. That having been said, the actual glyph designs were certainly not identical, especially with Helvetica versus Arial. And if you had a more current version of Helvetica or Times installed on your host system, there was no guarantee that the glyph complements and/or matching of particular characters in the host font matched that of the resident fonts on the printer.

There was also the hack in Acrobat and Reader that attempted to substitute missing fonts with synthesized Type 1 Multiple Master font instances from the Adobe Sans MM and Adobe Serif MM fonts bundled with Acrobat and Reader.

There were those of us within Adobe who vehemently opposed the idea of allowing PDF without embedded fonts. It didn't take much foresight to know the problems that this would cause, especially when viewing PDF files without all fonts embedded or for printing. Hate to say it, but we were right!!!

Interestingly, within the last 10 years of so (PDF and Acrobat are over 30 years old now), we were able to convince the Adobe teams to modify the “standard joboptions” to always embed all fonts (as “subsets” – only the glyphs actually referenced within the PDF file's text unless it was a PDF form in which full font embedding is employed).

Even the first version of PDF/X, (PDF/X-1a) required at least subset embedding of all fonts referenced in the PDF files' text. This requirement has been maintained in all PDF/X versions up to and included PDF/X-6 (which regrettably, although the RIP/DFE developers support, none of the graphic arts content creation software support).

Important note – it is total BS that it is safer to embed the full font in a PDF file as opposed to the subset of glyphs actually referenced by text in the PDF file. All you accomplish is bulking up the size of the PDF file and possibly slowing processing speed. Other than some CloneScript RIPs from 20 years ago or so, we have never seen printing problems with use of subsetted fonts! (Also note, embedding a full font does not, repeat does not, facilitate editing text of a PDF file in Acrobat – for such editing, the actual font itself must be installed on the user's system, Acrobat does not use any embedded fonts for text editing!)

Recommendations:

For files generated by modern graphic arts application versions (i.e., versions from the last 15 years or more), use the PDF/X-4 export/generation settings. Do not flatten transparency or convert all colors to CMYK unless you like degrading output quality. For preflighting such files, I recommend two steps. Use the Verify compliance with PDF/X-4 Acrobat Preflight profile. If that fails, depending upon the error detected, you could use the appropriate Convert to PDF/X-4 profile. You don't need any extra-cost software to accomplish this. The second step is to simply page through the PDF file on-screen and see if anything doesn't look quite kosher! (An optional third step I recommend to to print one copy of the PDF file from Acrobat - not MacOS File Viewer or similar non-fully PDF-compliant applications to a PostScript 3 printer.)

For files generated by other applications including Microsoft Office applications which don't directly support PDF/X (or any flavor), if you use Microsoft's native PDF creation (as opposed to the Save as Adobe PDF option provided if you have Acrobat installed), use whatever options are available to allow for font embedding. A number of available validation tests are available in Acrobat Preflight. I would strongly recommend the using the Font not embedded validation profile in the Essentials group of Acrobat Preflight. If that preflight profile finds one or more unembedded fonts and if any such fonts are actually installed on your system you can use the Embed missing fonts profile in the Acrobat Pro DC 2015 preflight profile group. As for the PDF/X-4 files, paging through the PDF file and printing one copy on a PostScript 3 printer are highly advised.

These steps could/should resolve most font issues although many more problems can arise. As previously indicated, if you start off with a PDF/X-4 file, at least from graphic arts applications (InDesign, Illustrator, Photoshop, Quark, Corel, etc.) many if not most printing issues can be avoided (other than those of the graphic designer making bad color and other design choices during document creation and layout)!

- Dov
 
Last edited:
Thanks for that history lesson Dov, very interesting! And thanks for busting the myth that embedding full font would allow PDF editing in Acrobat.
We actually had a customer not long ago that claimed that since the fonts in his PDF were BASE 14 fonts we should not stop his files in our preflight since "they will just look good anyway".
 
Ah, the mythical Base 14 fonts era.
I knew there was a number associated but conflated it with the number of system fonts provided by Apple which is/was a separate bygone issue. Some of us spent considerable parts of our (earlier) careers managing the associated issues. Many of those issues are now well managed by our software.
Thanks Dov. People (ahem) should note this conversation about the history of fonts.
 
Hello @nikleon71 ,

If you are interested in testing a less known software solution to detect and optimize PDF files in large quantities efficiently feel free to reach out to me. Disclaimer: I am the lead developer of a proprietary solution for digital print and reprographics providers that is mostly used in Germany.

Our solution can
  • warn about low resolution images and provide a neat report that identifies which page and which image(s) effected (no upscaling: fixing the source is recommended)
  • warn about existence of non-CMYK Images or Vector objects, (optimizer can optionally convert to CMYK)
  • warn about transparency (optimizer can flatten transparency by rasterizing)
  • warn about non-embedded or special fonts, (custom or exotic fonts names can be given) (optimizer can embed all missing fonts as proper PDF-fonts or as graphical 'outlines' as long as they exist on the system. Optimizer can create PDF/A as well which has all fonts embedded)
  • warn about dynamic annotations (like editable notes, editable boxes of markups) (optimizer can flatten annotations and keep content as vector)
  • warn about optional content layers that can be turned on/off (optimizer can flatten layers and keep content as vector)
  • write a new vector PDF that conforms to Adobe ISO32000 specification which cleans out most of the minor issues that RIPs complain about, as long as the input file is not too damaged

The "Preflight" and "PDF-Optimizer" functions are just one of many other functions. The software is under constant improvement for new functions as demand arises.
Anything that a high-volume professional environment user would want to do with PDF files can be done.

This software is NOT for low volume home users that wants to work on a couple of PDF files once a month with a few pages.
It is "industrial strength" for commercial users and dealing with 10,000+ pages is one of its design goals. It is "old school" desktop software with about 400 functions geared towards professional PDF users.

Any forum users that mention this post or contact me are welcome for a 30-day free trial version if they are running a commercial business.
Best Regards,
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top