Summary
Docxodus retains paragraph-after spacing immediately before a nested table, making each nested row taller than Microsoft Word renders it.
This was surfaced while adding Microsoft Graph Word-reference captures in PR #423 for the second-wave nested-table case from #400.
Reproduction
Render TestFiles/WC/WC043-Nested-Table.docx in paginated mode at 96 DPI.
The document default paragraph properties include:
<w:spacing w:after="160" w:line="259" w:lineRule="auto"/>
Evidence
The captured Microsoft Graph PDF and LibreOffice agree exactly on the four horizontal table-border rows:
| Renderer |
Horizontal border rows (px) |
Ink bounds |
| Microsoft Graph conversion |
96, 115, 133, 152 |
left 96, top 96, right 697, bottom 152 |
| LibreOffice |
96, 115, 133, 152 |
left 96, top 96, right 697, bottom 152 |
| Docxodus |
96, 125, 144, 163 |
left 96, top 96, right 697, bottom 163 |
The extra first-row height is approximately the declared 160-twip paragraph-after spacing (10.67 px at 96 DPI). Docxodus-versus-Word measured SSIM 0.96779 and worst ink F1 0.40694; LibreOffice-versus-Word measured SSIM 0.99986 and ink F1 1.0.
This settles the previous ambiguity: Word suppresses the paragraph-after spacing at this nested-table boundary.
Expected
A paragraph immediately followed by a nested table in the same cell should not contribute its normal paragraph-after spacing when Word suppresses it.
Actual
Docxodus converts the spacing to visible vertical space before the nested table, increasing nested-row heights by about 10–11 px.
Acceptance criteria
- Add a minimal generated DOCX regression containing a paragraph followed by a nested table inside a table cell.
- Assert the nested-table top/border geometry independently of font metrics.
- Suppress the paragraph-after contribution for the Word-equivalent boundary without changing ordinary paragraph-to-paragraph spacing.
- Rerun the tracked
nested-table visual-parity case and record the improvement.
Provenance
Microsoft Graph conversion reference: Microsoft Graph v1.0 DOCX-to-PDF conversion, rasterized at 96 DPI. The reproducible capture and measurement metadata are being added by PR #423; no Word artifact needs to be committed.
Summary
Docxodus retains paragraph-after spacing immediately before a nested table, making each nested row taller than Microsoft Word renders it.
This was surfaced while adding Microsoft Graph Word-reference captures in PR #423 for the second-wave
nested-tablecase from #400.Reproduction
Render
TestFiles/WC/WC043-Nested-Table.docxin paginated mode at 96 DPI.The document default paragraph properties include:
Evidence
The captured Microsoft Graph PDF and LibreOffice agree exactly on the four horizontal table-border rows:
The extra first-row height is approximately the declared 160-twip paragraph-after spacing (10.67 px at 96 DPI). Docxodus-versus-Word measured SSIM 0.96779 and worst ink F1 0.40694; LibreOffice-versus-Word measured SSIM 0.99986 and ink F1 1.0.
This settles the previous ambiguity: Word suppresses the paragraph-after spacing at this nested-table boundary.
Expected
A paragraph immediately followed by a nested table in the same cell should not contribute its normal paragraph-after spacing when Word suppresses it.
Actual
Docxodus converts the spacing to visible vertical space before the nested table, increasing nested-row heights by about 10–11 px.
Acceptance criteria
nested-tablevisual-parity case and record the improvement.Provenance
Microsoft Graph conversion reference: Microsoft Graph v1.0 DOCX-to-PDF conversion, rasterized at 96 DPI. The reproducible capture and measurement metadata are being added by PR #423; no Word artifact needs to be committed.