What a RIP actually does with your file

Four stages, and a failure at each

A RIP (raster image processor) is the software that turns your PDF into the pattern of dots a press, platesetter or large-format printer lays down. Knowing its four stages tells you where a job can fail.

1. Interpret. The RIP parses the PDF: page tree, fonts, images, vector operators, colour spaces. Failures here are structural: a corrupt file, a font it cannot decode, a PDF feature its version does not know about. Symptom: the job refuses outright, or one page comes out blank.

2. Flatten transparency. If the workflow cannot carry live transparency to the end, this is where it is resolved into opaque regions. In a PDF/X-1a workflow your application did it already; in PDF/X-4 the RIP does it, with full knowledge of the device. Failures here are the grey boxes and hairline seams from the earlier module.

3. Colour convert. Source colours are converted to the device’s space through profiles, honouring the output intent, spot colour definitions and overprint settings. Failures here are everything in the colour module: wrong profile, spot converted to process, white set to overprint and vanishing.

4. Screen and render. Continuous tone becomes halftone dots at the line screen and angles for that device, and the result is written as a raster for the imaging engine. Failures here are moiré, and dot gain if the curves are wrong.

Why a job times out

A RIP has finite memory and a time budget. Files that break it are almost always one of four things:

• Node explosion. A traced logo with 40,000 points, or a page where somebody outlined an entire book’s text.
• Deeply nested transparency. Groups inside groups with blend modes, each requiring its own compositing pass.
• Enormous embedded images, especially ones clipped down to a small frame so the RIP decodes 200 MB to paint 20 mm.
• Hundreds of clipping paths, each of which constrains the rendering of everything below it.

The fix is the same for all four: simplify before you export. Simplify traced paths, flatten what does not need to stay live, crop image data on export, release clips you do not need.

“It looks fine in Acrobat” is not proof

Acrobat renders your PDF with its own engine, on a screen, at low resolution, with anti-aliasing. The RIP renders it with a different engine, at 2400 dpi, with no anti-aliasing, converting colour and applying overprint.

Two things Acrobat hides unless you ask it to show them:

• Overprint. Off by default in the free Reader on some platforms. Turn on Acrobat’s Output Preview and the white-object-set-to-overprint failure becomes visible.
• Separations. The composite view looks correct even when your black text is made of four plates.

The honest test is not a screen view. It is the checks in the next few lessons, run against the exported file.

PostScript and why it still matters

Before PDF, jobs went to press as PostScript: a programming language the RIP executed. PostScript is Turing-complete, which meant a file could take unbounded time to render, and a printer could hang on a valid file.

PDF is a restricted subset with the programmability removed: a static description rather than a program. That is the main reason it replaced PostScript for delivery, and the reason it is safe to send a stranger a PDF.

You will still meet PostScript in two places: old workflows where a driver produces a .ps and a distiller makes the PDF, and EPS files, which are PostScript fragments. Both are worth avoiding when a direct PDF export is available, because the extra conversion is one more place for transparency to be flattened without your knowledge.

What to ask your printer

What RIP do you run, and does it handle live transparency? Do you want PDF/X-1a or PDF/X-4? Do you apply trapping in-RIP?

Three questions. The answers determine your export settings for every job you send them, so you ask once and write it down.

One more thing the RIP decides

The RIP, not your file, applies the device’s tone reproduction curve: the compensation for dot gain discussed in the colour module. This is why the same PDF sent to two printers with different presses produces two correctly different sets of plate values and, ideally, the same printed result.

It also means a file you have “corrected” by lightening the midtones because the last job printed dark is now doubly corrected, and will print washed out. If a job prints dark, the answer is the output intent or the press calibration, not an adjustment layer. Fix it upstream and tell the printer what you observed, rather than compensating blindly in artwork that will be reused.