Repository navigation
fix(docx): take a cell's last line hanging past its row out of the gap under the row - #827
Merged
Merged
Conversation
This was referenced Oct 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A one-line paragraph held to its inline icon (
holdPicturesInTheLine) has an exact Word line that reaches as far below the page's line as the icon's ink does, plus half a point. It gives that room back out of the space above what follows (hangingBelow).At the end of a table cell there was nothing following it, and
writeInCelldropped the hang. Word's cell then ended that much lower than on the page, and so did the row whenever that cell was its tallest.TimelineMinimal. The header is a row: name on the left, a contact stack on the right. The stack's last line, "GitHub", holds an 11pt icon lowered 2.5pt beside its text.What changed
writeInCell. At the end of a cell, the hang of its last line first comes out of the space the cell owes under it, before that space is written as the last paragraph's space below, as it comes out of the gap above the next block in the flow. Space a pull keeps from being written is not counted as room. What passes that space is left incellOverhang.writeRow. For each cell, it subtracts the room the row leaves that cell's child (roomBelowInItsRow).borderBelow, since Word's row is as tall as the taller of the two), is how much taller Word's row is.hangingBelow, so the next block takes it from its space above as it would from a band's.word-windows,libreoffice-windowsand their-linesfiles are rewritten for the three documents this moves.CHANGELOG.md, and the "Pictures and icons in a line" section ofdocs/recipes/docx-export.md, which said the row grows.Verification
Template corpus, re-measured in full in both editors. Three documents move; no line is lost and page counts are unchanged.
Corpus mean |drift| in Word goes 0.450 → 0.430pt, and in LibreOffice 1.807 → 1.783pt.
VioletGrid. Its header's contact cell ends with an icon line too, so everything under the header moves 0.48pt up.New test class,
DocxRowOverhangTest, four tests.Each test fails when its mechanism is taken out:
Full reactor gate:
./mvnw -B -ntp clean verify -pl :graph-compose-core,:graph-compose-render-pdf,:graph-compose-render-docx,:graph-compose-render-pptx,:graph-compose-templates,:graph-compose-testing,:graph-compose-qa,:graph-compose-coverage -amgives BUILD SUCCESS. render-docx runs 839 tests, qa 1814.Known limits
VioletGrid's first paragraph under its header (−0.37pt) and its education block carry offsets of their own, not found yet.Lane: shared-engine (render-docx). No public API change.