· AutomatePrint
Why big imposed PDFs slow down RIPs, and how we fixed ours
Cross-reference streams, dead objects, duplicated fonts and a clip on every piece: what makes a sheet of 5,400 stickers hard on a RIP, and what AutomatePrint's imposed PDFs now do about it.
A sheet of 5,400 die-cut stickers looks simple on screen. The RIP sees something else: thousands of placed pages, each with its own clip, and every font, image and colour profile those pages bring with them. How the imposed PDF is written decides whether the RIP spends seconds or minutes on it, and whether the press waits. This article explains where the time goes and what AutomatePrint's imposed PDFs now do about it, with numbers from our own tests.
Why big impositions slow RIPs down
A RIP doesn't print a PDF by reading it from top to bottom. It looks up objects (pages, fonts, images, drawing instructions) by number, interprets each page's content, and renders it at press resolution. Five things in an imposed file make that slower than it needs to be.
- A plain cross-reference table. The table that tells a reader where each object sits is, in a classic PDF, uncompressed text with one 20-byte line per object. PDF 1.5 added cross-reference streams and object streams: the index is a compressed binary stream, and many small objects are packed together into one compressed stream (ISO 32000-1, §7.5.7 and §7.5.8). Fewer bytes to read, fewer objects to look up one by one.
- Dead objects. Every incremental save appends a new section to the end of the file and leaves the old objects in place. Files edited many times carry versions of objects nothing uses any more. A RIP still has to parse the index for them, and they make the file bigger to transfer and spool.
- Duplicated resources. When each 1-up embeds its own copy of the same font or the same ICC profile, an imposition that combines them can end up with nine identical fonts and nine identical profiles. An embedded font or a press colour profile can easily run to hundreds of kilobytes.
- One copy, or one wrapper, per placement. PDF has a way to define content once and draw it many times: the Form XObject (ISO 32000-1, §8.10). An imposition that places the artwork as a new object for every piece makes the RIP treat 5,400 pieces as 5,400 different things. PDF/VT, the ISO standard for variable-data printing, is built on the opposite idea: content that repeats is defined once and referenced, so a RIP can prepare it once (ISO 16612-2).
- Clipping and transparency on every piece. Each clip path has to be computed and applied. A transparency group around each piece, isolated or knockout, asks the RIP to composite each piece in its own buffer before placing it, even when the artwork has no transparency at all.
What our imposed PDFs do now
- Each artwork page is embedded once. It becomes a single Form XObject, and every piece on the sheet is one short instruction that positions and draws it: move, turn, draw. A sheet of 5,400 stickers from nine artworks has nine artwork forms, however many pieces there are.
- Shared resources are kept once. Fonts, images and colour profiles belong to the artwork form, so they are never repeated per piece. When two different artworks embed the same font or the same profile, the file keeps one copy.
- Clips only where a piece needs one. A die-cut piece is clipped to its outline plus bleed, so neighbouring pieces never paint over each other. That clip is stored once, inside the artwork's form, not once per piece. A rectangular piece whose bleed box is its artwork's edge gets no clip path at all: the form's own boundary does the job. Pieces at fixed stations on a standing die keep their own clip, because their bleed depends on their neighbours.
- No transparency groups added. We don't wrap pieces in isolated or knockout groups, so the RIP composites only where your artwork itself uses transparency.
- A compact, clean file. Each sheet page has one content stream. The file is written in one pass with compressed object streams and a cross-reference stream (PDF 1.5 and later), with unused objects removed and duplicates merged. There is never an incremental update.
- Everything print needs comes through. Spot colours, overprint settings and the artwork's layers (trapping layers keep their on or off state, and are switched off on digital sheets) are unchanged. So are the non-printing Die and Stripping layers and the print marks.
The numbers
We imposed 5,400 generic stickers (nine shapes, 600 of each, turned in quarter turns) on one 48 × 96 in sheet. Each 1-up had vector artwork, an embedded font, a small image, an ICC-based colour and a spot white with overprint. We then rendered the sheet with Ghostscript and MuPDF, two widely used PDF interpreters, as stand-ins for a RIP.
- Building the PDF: 37.5 minutes before, 0.22 seconds now. The old code looked through every piece already on the sheet before adding the next one, so the time grew with the square of the piece count.
- File size: 7.6 MB before, 0.51 MB now (93 % smaller).
- Objects in the file: 10,895 before, 43 now.
- Form XObjects: 5,409 before (a wrapper for every piece), 18 now (one per artwork page, one per artwork clip).
- Content streams on the sheet: 5,400 before, 1 now.
- Embedded font files and ICC profiles: 9 of each before, 1 of each now.
- Cross-reference: a plain table before; a compressed cross-reference stream with object streams now.
- Ghostscript, reading and interpreting the sheet: 1.03 s before, 0.71 s now (31 % faster).
- Ghostscript, rendering at 100 dpi CMYK: 1.71 s before, 1.39 s now (19 % faster).
- MuPDF, rendering at 100 dpi CMYK: 0.52 s before, 0.43 s now (17 % faster).
Both interpreters are fast on this sheet either way; a production RIP does more work per object (colour management, trapping, screening), so the gain on your RIP will differ. What changes everywhere is how much the RIP has to read, look up and keep in memory. We also checked the output is the same picture. Rendered before and after, every piece lands within a thousandth of a point of where it was (the old file rounded its positions a little more). The only pixels that change are a few whose centre sits exactly on an edge.
While testing, we also fixed a placement error. When an artwork's bleed reached past the edge of its page, the old output scaled the artwork up slightly to fill the missing bleed. Artwork is now always placed at exactly 100 %.
A checklist for your own print PDFs
- Save, don't append. Use "Save As", or your tool's optimise option, before sending a file to print, so old revisions and unused objects are dropped.
- Prefer PDF 1.5 or later. Compressed object streams arrived in PDF 1.5; PDF/X-4 is based on PDF 1.6.
- Embed once, place many times. Ask your imposition tool whether a repeated artwork is stored once or copied for every piece.
- Watch for duplicate fonts and profiles. A preflight report that lists the same font or profile many times is a sign the file will spool slowly.
- Keep transparency where the design needs it. Live transparency is fine for modern RIPs. Extra groups that serve no purpose add work for every piece.
- Test with your largest job. A file that rips quickly at 20 pieces can still be slow at 5,000.
Sources
- ISO 32000-1:2008, Document management: Portable document format, Part 1: PDF 1.7 (Adobe's public copy): §7.5.7 Object streams, §7.5.8 Cross-reference streams, §8.10 Form XObjects.
- ISO 16612-2:2010, Graphic technology: Variable data exchange, Part 2: Using PDF/X-4 and PDF/X-5 (PDF/VT-1 and PDF/VT-2).
Read how the imposed PDF is built, see true-shape nesting, then compare AutomatePrint plans.