Skip to content

fix(docx): give a table the space it holds above and below itself - #712

Merged
DemchaAV merged 1 commit into
2.5-devfrom
feature/docx-table-spacing
Sep 22, 2026
Merged

DemchaAV merged 1 commit into
2.5-devfrom
feature/docx-table-spacing

Conversation

@DemchaAV

Copy link
Copy Markdown
Owner

Why

Word has no space above a table and none below one, so a table's own margin and padding
were dropped on the way out. A RowNode is exported as a one-row table, so a row's padding
went the same way.

Measured on the probe corpus through LibreOffice against the reference PDF, that was three
of the four gaps still missing from page 1 — a row's 14pt lost at each edge, and the 6pt a
billing table holds above itself:

123.2 → 108.1  −14.0  Scope    ← the row's top padding
221.8 → 192.7  −14.0  Notice   ← the row's bottom padding
317.0 → 282.2   −5.7  Item     ← the table's top margin

They looked like two defects (a row's padding, a header row) and were one.

What changed

A table-shaped node's own box goes through the same gap as everything else.
writeTableWithItsOwnSpacing owes its top edge before the table is written — the flush that
already runs before a table pays it onto the paragraph above — and owes its bottom edge
after, which the next paragraph writes above itself. So a table between two paragraphs now
reads as two paragraphs with a gap between them, and nothing needs an element of its own.

The one edge Word cannot hold is still dropped. A table with no paragraph above it loses
its top edge rather than getting an empty paragraph to carry it, which would be a line the
document never asked for. A test pins that, and pins that the bottom edge still arrives.

Verification

./mvnw -B -ntp clean verify over the eight-module gate → BUILD SUCCESS (core 815,
render-pdf 337, render-docx 225, testing 5, render-pptx 140, templates 127, qa 1784).
./mvnw -B -ntp test -f examples/pom.xml93 tests, BUILD SUCCESS; no committed preview
drifted.

Measured again on the same corpus and the same editor, page 1 end to end:

 57.1 →  57.5  +0.4  Quarterly service report
123.2 → 122.1  −1.1  Scope
221.8 → 220.7  −1.1  Notice
294.2 → 293.1  −1.1  Billing
317.0 → 316.2  −0.8  Item
400.8 → 399.6  −1.2  Additional storage

Every block is within 1.2pt of the page, against 87pt of accumulated drift three changes
ago. The residue is the 1.1pt the first paragraph starts with and never grows.

render-docx goes from 222 to 225 tests. DocxVerticalSpacingTest gains a table's two
edges landing on the paragraphs around it, a row's padding doing the same, and a table with
nothing above it keeping the bottom edge while losing the top.

Lane: canonical — document.backend.semantic.docx only. No public API change.

Page 2 is not touched by this and still drifts: Checklist sits 23.8pt high and the Lato
paragraph 37.4pt. That page opens with an image, so the next thing to measure is what an
image block reserves.

Word has no space above a table and none below one, so a table's margin
and padding were dropped. A row is exported as a one-row table, so a
row's padding went the same way: measured on the probe corpus through
LibreOffice, a row lost 14pt at each edge and a billing table the 6pt it
holds above itself.

Neither edge needs an element of its own. The space above a table is the
space below the paragraph before it, and the space below one is the space
above the paragraph after, so both go through the same gap every other
block goes through — a table between two paragraphs now reads as two
paragraphs with a gap between them.

What Word genuinely cannot hold is the top edge of a table with nothing
above it: there is no paragraph to carry it, and an empty one would be a
line the document never asked for. That edge is still dropped, and a test
says so.

With this and the two changes before it, the probe corpus's first page
renders within 1.2pt of the reference PDF everywhere, against 87pt of
accumulated drift before.
@DemchaAV
DemchaAV merged commit c50c5a8 into 2.5-dev Sep 22, 2026
12 checks passed
@DemchaAV
DemchaAV deleted the feature/docx-table-spacing branch September 22, 2026 23:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant