It paginates wrong
Content is cut off at the right edge of the page
A wide table, a long code block or a URL runs past the right margin and is simply not there. There is no scrollbar in a PDF, so the content past the edge is gone rather than hidden.
What is actually happening
The element is wider than the page's content box and has nothing telling it to wrap. On screen the page scrolls horizontally, so the content is merely inconvenient. On paper there is nowhere for it to go.
Confirming it is this and not something that looks like it
Set an outline on the offending element and look at where the outline ends. If it ends past the margin, the element is genuinely too wide rather than being clipped by an ancestor.
The fix
Give long unbreakable strings somewhere to break, and give wide tables a layout algorithm that respects the available width. table-layout: fixed is the single most effective change for wide tables, because the default algorithm sizes columns to content and will happily exceed the page.
/* Fixed layout distributes the available width instead of growing to fit. */
.document table {
table-layout: fixed;
width: 100%;
}
.document td,
.document th {
overflow-wrap: break-word;
}
/* Long unbreakable strings: URLs, hashes, reference numbers. */
.reference,
.document a[href] {
overflow-wrap: anywhere;
}
/* Code blocks wrap rather than scroll, because there is no scrolling. */
.document pre {
white-space: pre-wrap;
word-break: break-word;
}If that was not it
These produce the same symptom often enough to be worth ruling out before assuming the fix above did not work.
- A fixed pixel width on a container, set for a screen wider than the page
- white-space: nowrap inherited from a utility class
- Negative margins used for a full-bleed effect on screen
- A grid with a column sized in a unit that does not shrink, such as min-content on long content
Frequently asked
Does this happen with every rendering engine?
The behaviour behind it is not specific to one tool. The element is wider than the page's content box and has nothing telling it to wrap. Anything rendering HTML to a paged medium has to make the same decision, so the fix travels with you if you change how the render happens.
Will this show up as an error in my logs?
No, and that is what makes it expensive. A document that renders wrong is still a successful render as far as every log line is concerned. It is found by someone opening the file, which is usually the customer.
Related failures
Problems people arrive at from the same starting point, or mistake for this one.
Page breaks land in the wrong place
Nothing told the layout where it is allowed to break, so it breaks wherever the content runs out of page.
Table headers do not repeat on the next page
Header repetition is driven by table sectioning, not by styling.
There is an extra blank page at the end
Something extends a fraction of a millimetre past the end of the last page.
Page numbers are missing or all show 1
Page numbers come from the footer template's special classes, not from CSS counters in the document body.
Page margins are ignored in a generated PDF
Same collision as page size: a margin set in the render options and a margin set in an @page rule, with the engine picking one.
CSS for paged documents, and what actually works
Which parts of the paged media specification a browser-based render implements.
Everything that goes wrong, by category
The full list, grouped by where in the pipeline it breaks.
Paste your markup and see the rendered document, without signing up.