From d773801b43369ea111ed96d3075f1f5edc36cc8c Mon Sep 17 00:00:00 2001 From: Steffen Becker Date: Thu, 13 Aug 2026 20:16:27 +0200 Subject: [PATCH] docs: the first line of a page sits an ascent lower than LibreOffice's MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A font carries two ascents and the engines place the first baseline against different ones — OS/2 typo there, hhea here. Measured out of the bundled TTFs: 0.2021 em for Carlito, 1.85mm at 26pt and 0.84mm at 12pt, with every line after it matching on both sides. --- CHANGELOG.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index dc39b7c..5e5199b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -202,6 +202,15 @@ merely unimplemented belongs in the list above, not here. 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. +- The **first line of a page** sits slightly lower than LibreOffice's. Root cause: + a font carries two ascents, and the two engines pick different ones to place + the first baseline against the text-area top — LibreOffice the OS/2 typo + ascent, Chromium the hhea one its line box is built from. Read out of the + bundled TTFs that is 0.7500 against 0.9521 em for Carlito (Liberation Serif + 0.6934 against 0.8911): **1.85 mm at 26 pt**, 0.84 mm at 12 pt. Every line + after it matches — the line pitch is the same 1.2207 em on both sides — so it + is visible only on a page opening with a large heading. CSS exposes no way to + choose the other ascent. 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).