From b6a8db8584ab609bcc038e853e40742fba9661df Mon Sep 17 00:00:00 2001 From: Steffen Becker Date: Thu, 13 Aug 2026 01:28:59 +0000 Subject: [PATCH] docs: note the cell width a collapsed border costs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit With border-collapse Chromium takes the border's whole pixel off the cell's content width, where a word processor lays the line out between the cell margins regardless — 80.64px of text in a 95.77px column. Giving it back through the padding fixes the line it was measured on and breaks one two tables on, so the real offset is under 0.2mm. --- CHANGELOG.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 338f39a..43aa09b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -192,6 +192,15 @@ merely unimplemented belongs in the list above, not here. Chromium moves the whole run to the next line. `overflow-wrap: anywhere` would match it but also breaks runs LibreOffice keeps whole and shrinks a table column to its narrowest glyph. Noted 2026-08-09, revised 2026-08-11. +- A line **inside a table cell** has slightly less room than in Word/LibreOffice, + so it may take one word fewer. Root cause: with `border-collapse` Chromium + takes the collapsed border's whole pixel off the cell's *content* width, while + a word processor lays the line out between the cell margins whatever the + border is — measured at 80.64 px of text in a 95.77 px column against + LibreOffice's 21.59 mm. Giving the pixel back through the horizontal padding + was tried and reverted: it fixes the line it was measured on and breaks + another two tables on, so the real offset is under 0.2 mm — the same engine + rounding as above. See `tests/render-parity/README.md`. Noted 2026-08-13. - A text box anchored inside a paragraph loses the vertical offset it was anchored by: it is a block node here, so the importer lifts it out and it simply follows that paragraph (measured 4.7 mm on the thesis' figure page).