DOCX: w:wordWrap is not parsed, so a paragraph asking for character-level Hangul breaking still breaks at word level

[developer0hye]

Summary

w:wordWrap is Word's switch between Hangul word-level and character-level line breaking,
and office2pdf does not parse it. w:val="1" keeps Hangul eojeol whole; w:val="0" allows
breaking at any syllable. #626 implemented the word-level rule for every non-justified DOCX
paragraph, which is right for Word-authored documents but cannot honour a document that
explicitly asks for character-level breaking.

Blocked on an upstream change: the pinned docx-rs fork has no word_wrap field anywhere in
docx-core, so the value cannot reach ParagraphStyle until that lands.

Measured — native Microsoft Word for Mac one-factor probes

All variants of the same Korean text in the same document (host: 02_contract_ko.docx),
line-end x positions from the exported PDFs:

probe	paragraph properties	Word's breaking
PLAIN	no pStyle, no wordWrap	mid-eojeol (503.62 / 510.41 / 510.41)
PLAINWW1	<w:wordWrap w:val="1"/>	eojeol only (490.54 / 496.21 / 482.02)
PLAINWW0	<w:wordWrap w:val="0"/>	mid-eojeol
LIST	pStyle=ListParagraph	eojeol only
LISTWW0	pStyle=ListParagraph + w:val="0"	mid-eojeol — the property overrides the style

So w:wordWrap is the exact discriminator, and it overrides the style chain.

Why the golden mocks disagree with Word's usual default

02_contract_ko and 10_research_report_ko define no Normal style at all
(word/styles.xml is byte-identical between them, 4433 bytes, and w:docDefaults/w:pPrDefault
is empty). Their unstyled paragraphs therefore fall through to the Word application's own
built-in default paragraph style, which on a Korean install carries wordWrap=0. Adding an
empty <w:style w:default="1" w:styleId="Normal"> to styles.xml flips the same paragraph to
eojeol-only breaking — probe E, verified.

Observable today: 10_research_report_ko page 2's italic note paragraph is the corpus's only
non-justified mid-eojeol break in any Korean GT, and #626 keeps 표시되어야 whole where that GT
splits it (표|시되어야). That page goes 37/44 → 35/44 matched lines; every other line is
unchanged. It is a fixture artifact of the missing Normal style rather than behaviour a
Word-authored document exhibits.

Expected

w:wordWrap is parsed into ParagraphStyle and gates paragraph_eojeol_wrap, so a paragraph
declaring w:val="0" breaks at syllables even when it is not justified.

Actual

The property is dropped at parse time, so every non-justified Korean paragraph takes the
word-level rule regardless of what the document asked for.

Related: #626

Found in: the #626 fix-PR remediation, native Word 16.x one-factor probes (2026-07-31). Probe
documents and exports archived under /Volumes/T7/scratch/626/fix5/word_probes/.

[developer0hye]

Fixed in #790.

The dependency blocker is gone: docx-rs had no word_wrap field, added upstream in developer0hye/docx-rs#3 and merged into the fix/parse-tolerance branch this repo pins. That PR records both values rather than only the true case, unlike the neighbouring flags — w:val="0" is the setting that carries the instruction, and collapsing it to None is indistinguishable from the property being absent.

The value now reaches ParagraphStyle, merge_paragraph_style resolves it explicit-over-style as this issue's LISTWW0 probe requires, and paragraph_eojeol_wrap consults it before anything the paragraph inherits.

Measured on the same Korean sentence in a narrow column, three paragraphs differing only in the property:

paragraph	before	after
w:val="1"	…신뢰를 / 바탕으로…	…신뢰를 / 바탕으로…
w:val="0"	…신뢰를 / 바탕으로…	…신뢰를 바탕 / 으로…
absent	…신뢰를 / 바탕으로…	…신뢰를 / 바탕으로…

One caveat worth recording for anyone revisiting this: LibreOffice does not implement w:wordWrap. All three paragraphs above break identically in a LibreOffice 24.2.7.2 render, so it cannot serve as ground truth here — the native Word probes in this issue are the authority, and no GT image is attached for that reason.

Blast radius is nil: 0 of 59 DOCX under tests/fixtures/docx and tests/golden_mocks/*/sources/docx contain a wordWrap element, and of the 58 that convert, all 58 render byte-identically. The change only fires on a document that sets the property.

Also fixed a comment in typst_gen.rs that still described this issue as blocked on the dependency.