Summary
The 0.25em CJK/Latin auto-space is inserted at digit→Hangul boundaries inside a centred
(w:jc="center") paragraph where Word inserts none. The scope is correct everywhere else on
the same page — list paragraphs match Word to 0.04pt and justified paragraphs correctly get
zero — so the trigger is the centred paragraph specifically, not the auto-space model.
#627 covers the same auto-space applied inside table cells and explicitly names this
paragraph as a case it is not claiming, so this residual is untracked.
Measured
tests/golden_mocks/business/sources/docx/02_contract_ko.docx page 1, the centred date
paragraph 2026년 7월 17일 (10.5pt Malgun Gothic, not in a table), mutool trace:
| digit → Hangul boundary |
Word |
office2pdf |
6 → 년 |
−0.04pt (flush) |
+2.62pt |
7 → 월 |
−0.04pt (flush) |
+2.62pt |
7 → 일 |
−0.04pt (flush) |
+2.62pt |
| drawn line width |
79.43pt |
87.24pt (+9.8%) |
The line remains correctly centred (ink centre 297.65 vs Word 297.63 against a 297.6pt page
centre), so this is a metrics-scope error rather than an alignment error. It accounts for
~1000 of the 1554 differing pixels in the 438–448pt band of the 5% fuzz sweep.
Control cases on the same page, both correct: ListParagraph+numPr paragraphs measure
2.60/2.62pt against Word's 2.56/2.59pt at all 12 boundaries, and w:jc="both" paragraphs
measure 0 on both sides.
Reproduction
cargo run --release -p office2pdf-cli -- tests/golden_mocks/business/sources/docx/02_contract_ko.docx -o out.pdf
mutool draw -F trace -o - out.pdf 1 | grep -A2 '2026' # digit→Hangul gaps 2.62pt; Word flush
Expected
A centred paragraph gets the same auto-space treatment Word gives it — none at these
digit→Hangul boundaries — so the date line sets 79.43pt wide.
Actual
Each boundary gains 2.62pt, widening the line 9.8%.
Related: #627 #625
Found in: the #625 fix-PR visual audit (02_contract_ko.docx p1, committed Word GT, 150 DPI, 2026-07-31).
Visual comparison
| Compare |
 |
GT left, office2pdf right, 150 DPI, page 1 — the centred date line under 제5조.
Summary
The 0.25em CJK/Latin auto-space is inserted at digit→Hangul boundaries inside a centred
(
w:jc="center") paragraph where Word inserts none. The scope is correct everywhere else onthe same page — list paragraphs match Word to 0.04pt and justified paragraphs correctly get
zero — so the trigger is the centred paragraph specifically, not the auto-space model.
#627 covers the same auto-space applied inside table cells and explicitly names this
paragraph as a case it is not claiming, so this residual is untracked.
Measured
tests/golden_mocks/business/sources/docx/02_contract_ko.docxpage 1, the centred dateparagraph
2026년 7월 17일(10.5pt Malgun Gothic, not in a table), mutool trace:6→년7→월7→일The line remains correctly centred (ink centre 297.65 vs Word 297.63 against a 297.6pt page
centre), so this is a metrics-scope error rather than an alignment error. It accounts for
~1000 of the 1554 differing pixels in the 438–448pt band of the 5% fuzz sweep.
Control cases on the same page, both correct:
ListParagraph+numPrparagraphs measure2.60/2.62pt against Word's 2.56/2.59pt at all 12 boundaries, and
w:jc="both"paragraphsmeasure 0 on both sides.
Reproduction
Expected
A centred paragraph gets the same auto-space treatment Word gives it — none at these
digit→Hangul boundaries — so the date line sets 79.43pt wide.
Actual
Each boundary gains 2.62pt, widening the line 9.8%.
Related: #627 #625
Found in: the #625 fix-PR visual audit (02_contract_ko.docx p1, committed Word GT, 150 DPI, 2026-07-31).
Visual comparison
GT left, office2pdf right, 150 DPI, page 1 — the centred date line under 제5조.