WidthType.PERCENTAGE renders fine in LibreOffice and Word. Google Docs collapses the cell to one character per line.

Published August 4, 2026 · ZenMasterWorks

What actually happened

A disclaimer box — a bordered, shaded callout table with one row and one cell — was built into a generated joint-venture agreement template using docx (the Node.js library). The table and its single cell were both set to width: { size: 100, type: WidthType.PERCENTAGE }. The document was rendered to PDF with LibreOffice to check it visually before delivery. It looked correct: a wide box, full page width, readable paragraph text inside.

The person receiving the file opened it in Google Docs on a phone. The disclaimer box rendered as a column exactly one character wide, with every word of the paragraph broken onto its own line, running the full height of the screen. The rest of the document was unaffected — only the percentage-width table.

Why LibreOffice hid the bug

LibreOffice's DOCX-to-PDF export resolves WidthType.PERCENTAGE against the available page content width in a way that's forgiving of an unspecified or loosely-specified column grid. Google Docs' renderer does not resolve it the same way — when the underlying <w:tblGrid> column width wasn't set to an explicit, matching value, it collapsed the effective column width toward zero, and browser-style text wrapping did the rest: one character per line, because there was effectively no width to wrap within.

Checking the fix in only one renderer is the actual root cause here, not the percentage width itself. Word, LibreOffice, and Google Docs each interpret ambiguous OOXML sizing slightly differently, and a page can be pixel-correct in one and broken in another with no visible warning in either.

The fix

Table width, column grid width, and every cell width all need to agree, in dxa units, matching the page's actual usable content width (page width minus left and right margins, in twips):

new Table({
  width: { size: 9720, type: WidthType.DXA },
  columnWidths: [9720],
  rows: [new TableRow({
    children: [new TableCell({
      width: { size: 9720, type: WidthType.DXA },
      // ...
    })]
  })]
})

9720 twips here is a 12240-twip-wide page (standard US Letter) minus 1260 twips of margin on each side — the actual usable content width, not an arbitrary number. Getting this number right for a given page setup matters more than getting the syntax right.

How to actually verify it

Re-rendering in the same tool that missed the bug the first time doesn't prove anything. After applying the fix, unzip the .docx (it's a zip archive) and check word/document.xml directly for the literal string w:type="dxa" on the table, the column grid, and the cell:

unzip -p file.docx word/document.xml | grep -o '<w:tblW[^/]*/>'
unzip -p file.docx word/document.xml | grep -o '<w:tcW[^/]*/>'
unzip -p file.docx word/document.xml | grep -o '<w:gridCol[^/]*/>'

All three should report w:type="dxa" with matching widths. That's a direct check of what actually shipped, independent of which application happens to render it correctly.