The Preflight Checklist That Prevents Print Production Failures

Every print file must be checked against a documented specification, not against a vague sense of confidence. The gap between a file that prints cleanly and one that fails on the RIP is rarely luck. It is whether you verified content-level compliance against the Ghent Workgroup preflight specification or the ISO 15930-7 PDF/X-4 standard. Selecting a PDF/X-4 export preset in InDesign or Acrobat is a starting point. But the preset is a claim, not a verification. The export dialogue does not enforce that every placed image is in the correct colour space, that no font carries an embedding restriction, or that total ink coverage stays under the press tolerance. Each of these must be checked. The check must result in a pass or a fail against a known threshold, not a judgement call. What follows walks through every check required, states the exact specification value that constitutes a pass, and names the specific failure that occurs when the check is skipped. By the end, you will have a working preflight checklist you can run against any PDF before submission, and you will know why each item exists.

Print file preflight checks begin with the file format itself. The Ghent Workgroup specification, GWG 2020, and the ISO 15930 family mandate PDF as the submission format. The preferred flavour is PDF/X-4, which supports live transparency and ICC colour management. PDF/X-1a and PDF/X-3 do not support live transparency. They are unsuitable for files containing drop shadows, blends, or any object with an opacity value below 100%. A PDF/X-1a export of such a file will flatten the transparency, producing rasterised artefacts or incorrect overprints that appear only on press. The first check: is the file a PDF/X-4 with a declared output intent, and does the document content match that declaration? A common error report reads 'Output intent missing' or 'Output intent does not match destination profile'. The Fogra output intent, typically Fogra39 for coated stock or Fogra47 for uncoated, must be embedded in the PDF. If the file was created in an RGB workflow, the output intent is the destination for the conversion. A file with an RGB image and no output intent is a rejected file at most print shops, regardless of what the export preset was named.

The preflight specification for print is not a one-size-fits-all setting. It is a rule set that matches the press, the paper, and the finishing method. The Ghent Workgroup publishes the GWG 2020 Preflight Profiles, the international baseline for offset and digital work. These profiles encode the checks a prepress operator expects a file to pass: bleed, trim, safe area, colour spaces, resolution, fonts, and ink coverage. Using a generic PDF/X-4 preset without loading a preflight rule set is the equivalent of driving without a destination. The rule set tells the preflight engine that an image at 200 ppi effective resolution is a fail, not a warning, and that a total ink coverage of 340% on coated stock is acceptable but 360% is not. The GWG specification also covers the registration black rule: any element set to registration black (C100 M100 Y100 K100) must be used only for crop marks and registration marks, never for text or graphics. It prints on every plate and causes a registration halo when the press misaligns by even 0.1 mm. Load the GWG 2020 rule set into Acrobat's Print Production tool or InDesign's preflight panel. Run the file against it before you even look at the visual proof.

InDesign's live preflight panel is the first line of defence. It is only as good as the rule set it runs. The InDesign preflight panel errors that appear by default are a starting set: missing fonts, missing links, and overset text. For print work, you must extend the panel to run the Ghent Workgroup specification, which adds checks for bleed, slug, colour spaces, and output intent. A common error is 'Link RGB image in CMYK document'. This is a fail, not a warning. The RGB to CMYK conversion at export may be applied with a rendering intent that clips the gamut. Another frequent error is 'Font not embeddable due to licensing'. This appears when the OpenType fsType bit restricts embedding to 'preview and print' or 'editable' rather than 'installable'. The fsType mechanism has been stable for two decades. A font that blocks embedding will generate a PDF that may display correctly on screen but will substitute a default face at the RIP, altering line endings and page count. The InDesign live preflight panel will catch these if the rule set is configured to treat them as errors. If the panel shows zero errors but the file is not PDF/X-4 compliant, the rule set is wrong. The panel is a tool, not a guarantee.

Run the GWG Check and Triage Every Result

PDF preflight before sending to printer is the final automated gate. The tool is Acrobat Pro's Print Production module. The preflight engine in Acrobat can apply the GWG 2020 rule set, check PDF/X-4 compliance verification, and report on every rule. The output is a list of errors and warnings. Each must be triaged. An error is a fail that will stop the RIP. A warning may be acceptable if you have a documented reason. For example, a warning that an image has an effective PPI of 250 is a fail for a photographic image in a print job, because the offset press requires a minimum of 300 ppi at final size. A warning that a spot colour is defined in the file but not used on any page is a fail. It indicates a separation that will either print an extra plate or cause the RIP to skip it inconsistently.

Bleed, Trim, and the Report You Attach

The PDF preflight before sending to printer also verifies that the bleed is at least 3 mm (0.125 in) beyond the trim edge on all sides, the ISO 12647 standard for print work. If the file has no bleed, the trim will show a white edge on a full-bleed page. The job is reprinted at the printer's cost. Run the preflight, export the report, and attach it to the submission. A printer that sees a clean GWG report trusts the file more than one that arrives with no prior verification.

Here is the failure case that costs printers and designers real money. A designer exports from InDesign, names the file 'Final_PDFX4.pdf', and assumes the job is done. The printer's preflight ingests the file and finds that every image is RGB, the transparency was flattened to a raster layer, and the Fogra39 output intent is missing. The export preset was named 'PDF/X-4', but the preset was not verified. The actual content is a PDF 1.3 file with no output intent, which is PDF/X-1a at best. The claimed-versus-real gap: selecting a preset does not enforce content-level compliance. It only sets the export options. The RIP ingestion failure occurs because the file asks the RIP to convert RGB images on the fly without a destination profile, which may produce a colour shift across the run. The fix is to run the PDF preflight before sending to printer. It will report the actual compliance. If the report shows 'PDF/X-4 compliant' with zero errors, the file is a genuine PDF/X-4. If it shows 'No output intent' or 'RGB images without conversion', the file is not compliant, regardless of the file name. This is the single most important check, because it is the difference between a file that prints and a file that fails at the RIP.

The effective PPI resolution check is where most low-resolution image errors are caught. An image file may report 300 ppi in its metadata. But if it was upsampled from a 72 ppi source in Photoshop, the effective resolution at final size is what matters, not the stated value. The rule for offset print: a minimum of 300 ppi for continuous-tone images and 1200 ppi for line art. A common error report reads 'Image resolution is 150 ppi at final size'. The fix is to replace the image with a higher-resolution source. Do not increase the PPI value in the dialogue box; that only interpolates. The check is performed in Acrobat's Preflight as 'Resolution of images' with a threshold set to 300 ppi. If the file contains a placed image with an effective resolution below 200 ppi, the RIP will either rasterise it at a low sample rate, producing visible pixelation on the press sheet, or the press operator will reject the file for a contract proof. The metadata may say 300 PPI. The actual pixel dimensions divided by the physical dimensions in inches give the real number. For example, a 1500 × 1000 pixel image placed at 5 × 3.33 inches has an effective PPI of 300. Placed at 10 × 6.67 inches, the effective PPI is 150. The check is arithmetic, not opinion.

The Fogra output intent is the ICC profile that tells the RIP what the final print condition is. For coated stock, Fogra39 is the standard for ISO 12647-2. For uncoated, Fogra47 or Fogra40. The output intent must be embedded in the PDF. It defines the destination colour space for the conversion from RGB or Lab. If the output intent is missing, the RIP assumes a profile, typically SWOP for US printers, which shifts all colours. The total ink coverage limit (TIC) is a separate check: the sum of C+M+Y+K percentages must not exceed the press tolerance. For coated stock the limit is 300-340%. For uncoated it is 240-300%. A file with a rich black background of C60 M40 Y40 K100 has a TIC of 240%, which is safe. A file with C80 M60 Y60 K100 has a TIC of 300%, which is at the limit. A file with C80 M60 Y60 K100 plus a 100% black text overprint raises the TIC to 400%. It will not dry, causing set-off on the press and smearing on the delivery. The Fogra characterisation data specifies the maximum ink coverage for each paper type. The preflight rule set enforces it. If the file exceeds the limit, the press operator must either reduce the ink density, which changes the colour, or the job fails. The check is not optional. It is a binding constraint of the physical press.

Total ink coverage limit is not a single number. It is a range that varies by paper stock. The common prepress specification, based on ISO 12647-2, sets the limit at 300-340% for coated stock and 240-300% for uncoated. The reason: uncoated paper absorbs more ink, so a 340% ink load may not dry before the next sheet is fed. The preflight rule set must be configured with the correct limit for the paper that will actually be used. A common error is a rich black that uses C100 M100 Y100 K100 (registration black) instead of a rich black of C60 M40 Y40 K100. The registration black value, when used for text or graphics, prints on every plate. If the press misaligns, it creates a registration halo with a white or coloured fringe. The rich black overprint setting is different: black text over a coloured background should be set to overprint. The black ink prints on top of the CMYK colours, avoiding a knockout that would misregister. The overprint setting for white text is the opposite: white text must knock out, not overprint, or it disappears entirely on press. The preflight check for TIC is a failsafe against a file that will not dry. The overprint check is a failsafe against a file that misregisters. Both are non-negotiable for a press run.

The saddle-stitch page count divisible by 4 check is a binding constraint. It has nothing to do with content quality. It determines whether the final product can be physically assembled. A saddle-stitched booklet is created by folding sheets in half and stitching them through the spine. Each folded sheet produces four pages. The page count must be a multiple of four. A 20-page booklet will have a blank page when folded, because 20 is not divisible by 4. The printer must add a blank page, which looks unprofessional, or the job is rejected. The preflight rule set does not check page count; it is a job specification, not a file property. The check is manual: before submitting, divide the page count by 4. If the result is not a whole number, the document must be edited to add or remove pages. The same logic applies to bound books with larger signatures: the page count must be divisible by the signature size, typically 16 or 32. The failure case is a saddle-stitched catalogue that comes back from the bindery with a blank leaf, or pages out of order because the imposition was not calculated correctly. The page count is the first thing a bindery checks. No amount of preflight software can fix it.

Consider a typical preflight error report from a printer. It lists: '3 RGB images, no output intent, 5 missing fonts, 1 image at 150 ppi, total ink coverage 340%, spot colour 'Pantone 123C' unused, bleed 2 mm on left edge.' Each line is a specific failure, and each has a fix. The RGB images need conversion to CMYK against the Fogra output intent. The missing fonts must be embedded, or the text will substitute. The 150 ppi image must be replaced with a 300 ppi version. The 340% TIC is at the limit and may be acceptable on coated stock, but it is a warning. The unused spot colour must be removed. The 2 mm bleed is below the 3 mm standard and must be extended. The corrected file, after all fixes, passes the same preflight with zero errors. The difference between the two files is not visible on screen at 25% zoom. It is only visible in the preflight report. This is the claimed-versus-real gap: the designer claimed a PDF/X-4, but the file was not verified. The verification is the preflight, and the preflight must fail before it can pass. A file that has never failed a preflight has never been checked.

When a print file fails preflight at the printer, the designer is not called to discuss the weather. The file is rejected, the press is waiting, and the delay costs money. The failure case is the moment the printer's prepress operator sends back a PDF with a red X next to 'Preflight' and a list of errors that were not caught at the design stage. The normal route is to fix the errors and resubmit. But if the error is a font that cannot be embedded due to fsType restrictions, or an image that is 72 ppi with no source file, the fix may require rebuilding the layout from scratch. The 1am scenario: sending a file to a print-on-demand service that runs unattended overnight, and the file has a transparency artefact that causes a black box on the page. The service's preflight rejects it. The designer wakes up to a failure email. The defence is the preflight checklist, run before submission. Every item here is part of it. If your file fails, go back to the preflight report, not the visual proof. The report is the only place where the error is named.

This subject suits the adjacent professional: the developer, marketer, or content writer who commissions print and needs to speak the specification language without being sold mystique. It also suits the designer who has been burned by a failed print run and wants to understand why. It does not suit the user who wants colour psychology as a primary decision-making framework. This subject addresses colour only where evidence exists, such as the legibility research behind black text on white. It does not suit the user who believes that a PDF/X-4 preset is a guarantee. The preset is a claim, not a verification. The right reader for this subject is the one who is actually going to send a file to a printer, and who wants to arrive prepared. The wrong reader is the one who wants a single number for a safe area. The answer is always 'it depends on the printer'. Any source that gives a single value without verification is selling a shortcut that does not exist.

The sentence is: 'A file that has never failed a preflight has never been checked.' This is a specific opinion about the nature of preflight verification that no competitor would use, and it anchors the entire argument that a preset is not a pass.