Handle wide and multi-page tables in pdfmake

pdfmake does not automatically make every wide or multi-page table safe. Reproduce the exact data shape, calculate available width, set column widths deliberately, and test page breaks with the longest expected rows. Open project issues document separate cases for wide tables, row spans across pages, and oversized rows used with dontBreakRows. Treat those reports as test inputs for your pinned version, not as proof that every table fails.

What happens to tables wider than the page?

According to issue #441, opened on November 18, 2015, pdfmake has no automatic handling for tables wider than the printable page area. The original reporter asked: "I haven't been able to find any documentation or issues about how to handle tables with many columns, causing the table to be wider than the page width."

Related project issues document additional width and pagination cases:

• #203: table content pops outside page container with dynamic data and auto widths
• #968: request for percentage-based table widths (not supported)
• #1129: table width values not applying correctly
• #2179: inconsistent total table widths above 600pt threshold
• #2333: request for auto columns that still fill full page width
• #44: how to make table width 100% of page size (opened July 2014: the issue predates #441)

The root cause: when columns use 'auto' width, pdfmake calculates each column's minimum content width and renders at that size regardless of whether the total exceeds the page. When columns use '*' (star/flexible) width, pdfmake distributes remaining space equally, which produces columns that are often too wide or too narrow for their content.

pdfmake's document-definition model is not a browser layout engine. Do not assume CSS overflow or horizontal pagination behavior. Verify the result produced by the exact version and fonts you ship.

2. rowSpan across page breaks

According to issue #1597, opened January 3, 2019, tables with rowSpan cells render incorrectly when the table crosses a page boundary. The reporter tested every available option, dontBreakRows, keepWithHeaderRows, pageBreakBefore, in all possible combinations. None resolved the issue.

The symptoms vary depending on where the page break falls relative to the spanned cell:

• Content overflow: the spanned cell's content bleeds into the next page's header area or overlaps with subsequent rows (documented in #1597)
• Missing content: merged cells on the second page display no content at all, even though the data exists in the document definition. According to issue #2584 (May 2023), "the merged cells on the second page do not display content."
• Missing borders: according to issue #2270 (June 2021), "table cells with rowspan don't render the bottom border correctly when spanning multiple pages"
• Header corruption: according to issue #470 (December 2015), headers with colspan and rowspan are rendered correctly on the first page but lose their span structure on subsequent pages

These reports identify failure cases worth adding to a table-heavy document test suite. They do not establish a failure rate for pdfmake as a whole.

Why does dontBreakRows make rows disappear?

The dontBreakRows option was designed as a partial solution: it prevents a table row from being split across a page break, instead pushing the entire row to the next page. But according to issue #1159 (October 2017), this creates a worse problem: if a single row's content is taller than the available page height, the row is silently dropped.

The reporter demonstrated the behavior with a simple example: a table with dontBreakRows: true where one row contains enough text to exceed a full page height. The row vanishes from the PDF with no error, no warning, and no indication that content was lost.

The issue asks for an option that avoids row breaks unless the row is too tall. Check the current issue and release notes before relying on the reported behavior; this article was reviewed on 8 September 2026.

Both settings need fixtures that approach and exceed a page height. Choose a documented policy for splitting, clipping, rejecting, or continuing oversized rows.

Workarounds to evaluate

For wide tables (bug 1)

Workaround A: pre-calculate column widths. Before passing the table to pdfmake, calculate the available page width (page width minus left and right margins) and distribute it proportionally across columns based on content width ratios.

const pageWidth = 595.28; // A4 in points
const margins = 40 + 40; // left + right
const available = pageWidth - margins;

const columnRatios = [0.15, 0.35, 0.25, 0.25];
const widths = columnRatios.map(r => r * available);

// use fixed widths instead of 'auto' or '*'
const table = {
  widths: widths,
  body: [/* ... */]
};

This requires knowing the column count and an expected content envelope. Add overflow tests when content length varies.

Workaround B: zero-width spaces for text wrapping. According to a February 2026 SAP Community blog post, inserting zero-width space characters (\u200B) at regular intervals into long strings allows pdfmake to find break points. This prevents single-word overflow but does not solve the multi-column width problem.

function addBreakPoints(text, interval = 10) {
  return text.replace(
    new RegExp(`(.{${interval}})`, "g"),
    "$1\u200B"
  );
}

For rowSpan page breaks (bug 2)

Workaround: flatten the data. Restructure your data to avoid rowSpan entirely. Instead of a merged cell spanning 3 rows, repeat the cell content in each row with visual styling (matching borders, no top/bottom borders on inner rows) to simulate the span appearance. This is verbose but avoids pdfmake's broken rowSpan rendering.

For dontBreakRows disappearing rows (bug 3)

Workaround: cap row height. Before generation, estimate each row's content height. If any row would exceed the page height, split it into multiple rows. This requires measuring text height (accounting for font size, line height, and column width), which pdfmake does not expose as a public API.

Release checklist for table-heavy PDFs

Issue trackers are evidence of reproducible cases, not a substitute for testing your own document. Before release, keep fixtures for these boundaries:

• the widest supported column set at the smallest page size;
• a long unbroken identifier, URL, or account number in every text column;
• a row that almost fills a page and a row that exceeds one page;
• a page break inside each supported rowSpan pattern;
• repeated headers on the second and later pages;
• every font and font weight used in production.

For each fixture, assert that generation completes, the output opens, the expected text is present, and page count stays within a reviewed range. Add a rendered-page comparison when table geometry matters. A byte-level success response alone cannot detect clipped cells, missing borders, or a row placed outside the page.

When to change the document design or renderer

Keep pdfmake when you can constrain widths, content length, and span patterns. Change the document design when a simpler table conveys the same information: split wide tables into sections, move secondary fields to a details page, repeat group labels instead of spanning rows, or offer landscape output.

Evaluate a different renderer when the required table behavior cannot be expressed or verified with your pinned pdfmake release. HTML-to-PDF tools use browser or CSS-paged-media layout; low-level PDF libraries give you direct drawing control; structured document engines expose their own table contracts. Each choice needs the same adversarial fixtures because none of those categories guarantees correct pagination for arbitrary input.

Runstamp's pdf.render operation accepts a bounded document contract and returns operation diagnostics with the artifact. Use pdf.validate as a separate structural check, then inspect representative rendered pages before distribution. The pdfmake comparison describes the product boundary; it does not replace a test against your real templates and fonts.