PDFPipe

Print finishing / Collating, assembling and signing off

Tab dividers in a printed manual, and where the tabs actually sit

Divider sheets whose tabs extend beyond the edge of the document, cycling down the page so that every tab is visible at once.

What is physically going on

A tab divider is a sheet wider than the pages around it, with the extra width cut into a tab. The tabs are positioned so no two in a set sit at the same height, which is what lets a reader see all of them from the closed document, and they cycle: once a set is exhausted the next divider starts again at the top. That means the number of dividers and their order is not a design detail, it is a physical arrangement bought from a supplier in fixed configurations, so the document has to be organised around the tab set available rather than the other way round.

The decisions

Reasons rather than a description of the code. Where a number depends on the stock or the press, the instruction is to get it from the printer rather than to quote one here, because spine width, creep and bulk are not constants.

  • Decide the number of sections before the design, because the tab set comes in fixed sizes and the sections have to fit it.
  • Keep tab text short. The tab is a few millimetres of usable width and a long section name will not fit on it.
  • Print the tab text on both sides if the divider is read from both, since a tab is visible from either direction in a bound document.
  • Remember the divider is a different sheet size from the body, so it is a different page in the document, or a separate file supplied alongside.
  • Keep the divider's own page content clear of the tab area, and clear of the bound edge, since it is bound with everything else.
  • Order the tabs to match the document, and check the order on a physical set. A reversed tab set is a common and irritating error.

What it means for the page rule

The page rule is the part of this a document author controls. The binder decides the gutter and the printer decides the creep allowance; the document's job is to leave the room those decisions need.

css
/* A divider is a different sheet size, so it is a named page rather
   than a variation of the body page. */

@page divider {
  /* wider than the body page: the extra width becomes the tab */
  size: 223mm 297mm;
  margin: 20mm 30mm 20mm 30mm;
  @bottom-right { content: ""; }
}

.divider {
  page: divider;
  break-before: right;      /* a divider faces the section it opens */
  break-after: page;
}

.divider h1 {
  font-size: 24pt;
  /* clear of both the tab edge and the bound edge */
  margin-right: 26mm;
}

/* The tab text itself is usually supplied to the divider maker
   separately, because the tabs are cut and printed as a set. */

What people do instead

Designing the section structure first and buying tabs afterwards. Tab sets come in fixed counts, so a document with seven sections and a five-tab set means either two sections share a tab or a second set starts, and both of those are decisions better made before the contents page is written.

How to find out rather than assume

Get a physical tab set and lay it against a printed dummy. Every tab should be visible from the closed document, in the right order, with its text legible and inside the cut. Then check the divider's own content clears both the tab and the binding.

Where this API sits in it

Outside it. This API renders HTML to PDF: it produces a sequence of pages at the size and margins your CSS and the render options set, and everything on this page happens afterwards, to paper, in a bindery. There is no imposition option, no binding option and no finishing option, and there could not be, because none of those are properties of a file. What the render does decide is the two things finishing cares about most: how many pages there are, and how much room is left at the edges. Both of those are set before anything is printed, which is why a finishing constraint discovered late is expensive and one designed for is free.

Frequently asked

Can the API impose the pages into printer spreads?

No, and you should not want it to. Imposition is done by the printer with tooling built for it, against the specific press, stock and folding scheme, and the input that tooling wants is single pages in reading order, which is what a render naturally produces. Supplying anything else means somebody has to undo it first.

How do I get the page count to a multiple of four?

By deciding where the padding goes rather than letting it land at the end. Add the blanks deliberately, style them with the blank page rule so they carry no folio or running header, and mark them as intentionally blank if the document is formal. Counting the covers into the total is the step people miss.

Do any of these apply to a document that is only ever read on screen?

No. This cluster is about physical operations on paper, so if a document is genuinely never printed, none of it is your problem. It is worth checking that assumption rather than making it: delivery notes, permits, method statements and invoices all end up on paper more often than the people generating them expect.

Related finishing topics

The operations that constrain each other, then the rest of the same group.

None of this is a render option, and none of it could be. What the render controls is that the page count and the margins are the ones the finishing needs.