Print-Ready Output

There is a moment, early in every designer's career, when they send a file to a printer without checking it properly and get back something unexpected. The colors are different. The margins are wrong. Text is cut off at the edge. An image that looked fine on screen has a white border around it where the bleed should have been. This moment is expensive and educational in roughly equal measure, and its lesson is simple: the PDF you generate is not automatically print-ready. It is a document that you must inspect, verify, and in some cases adjust before it is ready to be sent anywhere. This chapter is about doing that work correctly.

It covers the technical requirements that professional printers impose on submitted files — bleeds, crop marks, safe zones, color modes — and explains how to achieve each of these in a Paged.js workflow. It then walks through the process of generating the PDF itself, the checks you must make before submitting it, and the specific considerations that apply when working with print-on-demand services rather than traditional offset printers.

Bleeds and crop marks Preparing for the physical cut

When a printer produces a book or document, the paper is larger than the finished trim size. After printing, the sheets are cut down to the final dimensions — a process called trimming. The cut is made with physical blades that cannot be positioned with perfect precision; there is always a small tolerance, typically ±1–2mm. This means that if your design extends exactly to the edge of the trim — if the background color or an image goes precisely to the margin of the page — a slight variation in the cut can leave a thin white sliver of unprinted paper at the edge, or alternatively can cut slightly into the design. Neither is acceptable.

The solution is the bleed: an extension of the design beyond the trim edge, typically 3mm on all sides (some printers require 5mm; check the specification). The bleed ensures that even if the cut is slightly outside the trim line, the design still extends to the physical edge of the paper. Only elements designed to extend to the page edge — backgrounds, full-bleed images, colored borders — need to be extended into the bleed area. Body text and other content must remain within the safe zone — typically 5mm inside the trim on all sides — to ensure it is not cut off even if the trim is imprecise.

In Paged.js, bleeds are specified in the @page rule using the bleed property, and crop marks are enabled with the marks property. These are CSS Paged Media properties that Paged.js supports:

@page {
  /* Page trim size                              */
  size:    5.5in 8.5in;

  /* 3mm bleed on all sides                     */
  bleed:   3mm;

  /* Crop marks + registration marks            */
  marks:   crop cross;

  /* Standard margins inside the trim           */
  margin-top:     0.75in;
  margin-bottom:  1in;
  margin-inside:  0.625in;
  margin-outside: 0.875in;
}

/* Elements that bleed must extend 3mm beyond
   the page edge. Position them with negative
   margins to reach into the bleed zone:       */
.full-bleed-background {
  margin-left:   -3mm;
  margin-right:  -3mm;
  margin-top:    -3mm;
  margin-bottom: -3mm;
  padding:       3mm; /* restore internal spacing */
}

The marks: crop cross value generates two types of marks: crop marks (short lines at the corners indicating where to cut) and cross-hair registration marks (small crosshairs used by the printer to align color plates). For a single-color or digital print job, registration marks may not be needed; marks: crop alone is sufficient. For commercial offset printing with multiple color plates, always include both.

Color for professional printing Understanding what happens to your RGB values

Screen design uses RGB color — red, green, and blue light combined in varying intensities to produce any color. Professional printing uses CMYK — cyan, magenta, yellow, and black inks applied to paper in varying densities. These are fundamentally different color models, and the conversion between them is imperfect. Colors that look identical on screen may look different in print, and some RGB colors — particularly vivid blues and greens that fall outside the CMYK gamut — cannot be reproduced accurately in print at all.

For most document work produced through Paged.js, this is a manageable concern rather than a critical one. The text, which makes up the majority of the page, is black or near-black — this converts perfectly from RGB to CMYK (black is K: 100% in CMYK). Muted, desaturated colors — the warm grays, off-whites, and subdued accents recommended in Chapter 5 — also convert predictably. The main risk areas are vivid colors used for decorative purposes: bright accent colors, saturated image backgrounds, vivid callout tints.

The practical approach to color management in a Paged.js-to-print workflow is threefold. First, use the desaturated palette strategy from Chapter 5 — keeping saturation below 60% for all design colors ensures they fall within the safe range of the CMYK gamut. Second, where possible, specify colors in a way that maps cleanly to print — a warm accent defined as hsl(25, 42%, 30%) will convert to CMYK with a predictable brownish-amber result; a vivid hsl(210, 95%, 55%) will convert to a noticeably different blue than it appeared on screen. Third, if the document contains critical brand colors or colors where accuracy is essential, consult with your printer about whether they can accept a PDF/X format with embedded ICC color profiles, which gives the printer's software more information about how to handle the color conversion.¹

For The Compositor's Garden and most literary documents, color management is not a significant concern — the palette is near-neutral, and the only chromatic color is the warm amber accent used for decoration rather than information. This palette converts predictably, and the output from a standard PDF print job will closely match the screen preview.

Generating the PDF The step-by-step process

Paged.js generates PDFs through the browser's built-in print function — not a dedicated export tool. This is both its strength and its limitation. The strength is that it requires no additional software beyond the browser and Paged.js itself. The limitation is that the quality and consistency of the PDF output depends on the browser's PDF engine, which varies between browsers and platforms. For production PDF output, Chromium-based browsers — Chrome, Edge, or the headless Chromium used in automated pipelines — produce the most consistent and highest-quality results.

Checking the PDF A preflight checklist

Professional print workflows include a preflight step — a systematic check of the submitted file against the printer's requirements before printing begins. Even for documents printed through print-on-demand services or desktop printers, performing your own preflight reduces the risk of expensive surprises. The following checklist covers the most common points of failure for Paged.js documents submitted for printing.

Working with print-on-demand Services, specifications, and practical advice

Print-on-demand (POD) services — IngramSpark, Lulu, Amazon KDP Print, and others — allow books and documents to be printed in small quantities, or even single copies, without the minimum runs and upfront costs of traditional offset printing. For a document produced with Paged.js, these services represent a natural distribution channel: the same workflow that produces a screen-readable PDF can, with appropriate preparation, produce files ready for POD printing.

Each POD service has its own file specifications, and you must check them carefully before submitting. The most common requirements are: PDF/X-1a or PDF/X-4 format (a standardised PDF subset designed for reliable print exchange), specific page sizes matching the service's available trim sizes, 3mm or 0.125-inch bleeds if any design elements extend to the page edge, and embedded fonts. Most services also require a separate cover file, which is outside the scope of a Paged.js interior document but worth noting.

The Chromium-generated PDF that Paged.js produces is a standard PDF rather than a PDF/X variant. For services that require PDF/X specifically, you will need to convert the Chromium PDF to the required format using a tool such as Adobe Acrobat Pro (which can convert to PDF/X through its Print Production tools) or Ghostscript (which can convert on the command line). This conversion step does not change the visual content of the document; it adds the metadata and constraints that PDF/X requires.²

One practical consideration for POD submission: Chromium generates PDFs with compressed streams and efficient file structures, which typically produces file sizes well within the limits imposed by POD services (usually 400–500MB for interior files). Image-heavy documents may produce larger files; in this case, Ghostscript can be used to reduce the PDF file size while maintaining visual quality, using the -dPDFSETTINGS=/prepress flag which optimises for print quality.

The Compositor's Garden is done. It exists as a PDF, it can be printed, and every decision in it — from the typeface and the type scale to the margin proportions, the running headers, the break controls, and the color palette — was made consciously, for reasons that can be articulated and defended. This is what it means to typeset with intention rather than instinct.

Part Five turns from the project document to the broader applications of what we have built. Chapter 20 begins with the long-form report — a document type with its own conventions, its own hierarchy challenges, and its own relationship between data and prose that requires fresh thinking about structure and layout.