Honest note: no LibreOffice on this machine, so a pixel-level comparison of one docx across two renderers is not possible here. This page lists what to check, not comparative results — the numbers come when there is an environment.
Misalignment in docx almost always comes from the items below. Their common trait: the spec leaves freedom, and renderers fill it differently.
| Where it drifts | Why | How to check |
|---|---|---|
| Font fallback when missing | The named font is absent, a substitute has different metrics, lines reflow | Open on a machine without that font and see if it still fits one page |
| Line spacing and paragraph spacing | Multiple spacing is rounded differently | Check whether paragraph count changes or widows appear |
| Automatic table column width | Computed from content by different algorithms | Fix column widths, then compare |
| Pagination and widow control | Different implementation detail | Check whether key headings get pushed to the next page |
| Image and text wrapping | Wrapping implementations vary considerably | Focus on mixed image-text paragraphs |
| Tabs and indents | Default tab stops differ | Check alignment-by-tab areas like TOCs and signature blocks |
Reduce risk at generation time
- Use only ubiquitous fonts. No rare typefaces.
- Use absolute line spacing (points, not a multiple).
- Hard-code table column widths instead of leaving them automatic.
- Avoid text boxes: the most drift-prone element.
Shortest verification path
- Generate the docx.
- Open in Word (or WPS) on your machine and export a PDF as the baseline.
- Open on another machine with another renderer and compare key pages: first, any with tables, last.
- Compare only those, not every word — structure matters, not pixels.
If you have no second renderer
Fallback: export the docx to PDF yourself. PDF layout is fixed, so comparing PDFs at least confirms your own layout is stable. It does not replace cross-renderer checking.