Put a Table in a PDF That Survives Printing

There is a reliable way to put a table in a PDF and have it fall apart. Type the rows into an ordinary paragraph, set it in a monospaced font, and push spaces around until the columns line up in the box you are typing into. It looks correct right up to the moment you export.

It fails because a text block knows nothing about columns. Each line is split on whitespace and rejoined with single spaces before it is measured, so every run of spaces holding your columns apart becomes one space. Monospacing does not rescue it: the spaces doing the aligning were gone before the font was ever consulted.

The document builder has a real Table block for this. It behaves differently enough from a table on a web page that the differences are worth knowing before you build something wide.

A table in a browser is a set of instructions. The reader's window decides the width, the reader's text size decides the height, and the whole layout is recomputed whenever either changes. That is what lets a web table be responsive at all.

A PDF has none of that. Every glyph carries a position, the rules around the cells are vector lines with fixed coordinates, and no reader recalculates any of it. Whoever exports the file makes every width decision once, for everybody. A table that does not fit is not rescued at the other end: it is printed as it is, or shrunk with the rest of the page.

It genuinely cannot, and that is the first thing to understand. The table width is set as a percentage, from 5 to 100, of the text column, and the text column is the paper minus the margins. On Letter paper with the normal margin preset that ceiling is 468 points, and a table set to 100% is exactly that wide.

There is therefore no overflow to manage and no silently clipped final column. The pressure from content that wants more room lands on the column widths instead.

Each column is measured against the widest unbroken line any of its cells contains, and the results are fitted to the width available. If they add up to less than the table width, every column is scaled up by the same factor, so a table always fills the width it was given while keeping the shape its content asked for. If they add up to more, every column is scaled down by the same factor and the text wraps inside its own cell.

Scaling down has a floor. A column cannot be squeezed below its own padding plus roughly two characters' worth of its font size, because a column narrower than that cannot wrap at all. A column that would fall below the floor is pinned there and drops out of the pool, and the wider columns give way instead. If not even the floors fit, every column takes an equal share.

Several of the starting points here ship with fixed column proportions rather than measured ones. The invoice is the clearest: its description column is set several times wider than its quantity column. Those numbers are weights rather than points, normalised across the table, so changing the paper or the margins keeps the same proportions inside a different total width. A hand-tuned point width could never do that.

There is a sharp edge in it. A set of weights has one entry per column the table was built with. Add a column and there is no weight waiting for it, so the new one is given no share of the width at all. The preview shows it immediately, and the fix is to rebuild the table rather than fight it.

Mark the first row as a header and it is set in bold on a filled background. A second checkbox, on by default, draws it again at the top of every page the table continues onto. That is the difference between a readable long table and a wall of unlabelled figures on page four.

Row breaking follows one rule with one exception. A row that would be cut across a page boundary moves whole to the next page instead. The exception is a row taller than an entire page: that one is split, because moving it would send it bouncing from empty page to empty page forever.

• It wraps inside its own column, and the row grows to the tallest cell in it. That is the whole difference between a table and text arranged to look like one.
• It holds text. Not an image, not a nested table, not a second block.
• Cells do not merge, across either columns or rows. A single heading spanning three columns is not available.
• Emphasis is by row, not by cell. A filled header row and alternating body fills are the supported shading. There is no per-cell background and no per-cell vertical alignment.
• The controls apply to the whole block. Font, text size, rules and width are set for the table; the right-aligned money column in the invoice is part of that starting point, and typing into one of those cells keeps its alignment.

The border setting is a full grid, row rules only, or none at all, and the rules are vector lines rather than typed characters, so they print as lines rather than as rows of hyphens. Row rules only is usually the better choice on paper: a full grid at a small text size reads as noise, and the eye follows a row perfectly well with one rule under it.

Table text defaults to 11 points against the 14 points of body text, and that gap is deliberate. A point or two smaller is often exactly what keeps a set of columns above their floor, and it is the first thing to try when the columns are fighting each other.