fix(docx): break a paragraph's lines where the page does, though Word sets its size to the half point - #804
Merged
Merged
Conversation
…ize takes, so they break where the page breaks them
…d a wrapped paragraph's a point clear of the next word
…nd never narrow a paragraph of one line
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
Word states a type size in half points, so a size the page sets to the tenth is set a little larger or smaller, and each of its lines that much wider or narrower. Lines then break at other words than on the page.
In Word,
EngineeringResume's columns stood 8 to 9pt low (median drift 7.9pt):Scaling the glyphs (
w:w) was ruled out before, as a scale stays on the text a reader types next.What changed
measureAtWordsSize/wordsMeasure(called fromwriteParagraph). A paragraph set flush left gets a measure as much wider or narrower as Word sets its text, through its right indent.EngineeringResume's projects mix a 7.35pt title (set at 7.5) and 7.1pt prose (set at 7). Averaged over the paragraph, the measure narrowed, and the title's line broke at another word in both editors.CompactMono's "and", 0.1pt off on the page, fitted in Word.OrangeOps' phone number, as wide as its column, broke in LibreOffice a point narrower.room, the cell's measure in a cell.letTheLineStandOutalready gave room past its box.CHANGELOG.md; the half-point paragraph ofdocs/recipes/docx-export.md, which said the rounding was not made up for.Verification
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 (core 818, render-pdf 339, render-docx 768, templates 142, testing 127, qa 1791).DocxWordSizeMeasureTest(new, 10 tests).w:sz=16and widened.Each piece fails its own test when taken out. Leaving pictures out of the line fails the picture test. Averaging over the letters fails the title test (and four others). Narrowing a line of one fails the one-line test. Dropping the point of clearance fails the near-tie test. Dropping the alignment guard fails the centred test.
Template corpus (62 documents), against
2.5-dev. Word, lines more than 2pt from the page:EngineeringResumeNordicCleanClassicSerifSerifHeadline2.5-dev, lines lost to another word counted too:DocxFidelityCorpusTestpasses against2.5-dev's baseline. That gate caught the averaged share's lost lines inEngineeringResume, and the first clearance's inOrangeOps.ClassicSerif), against 12.4pt before.Known limits
Lane: shared-engine (render-docx). No public API change.