DOCX: a body w:framePr paragraph is laid out in the flow instead of as a positioned frame that text wraps around #2231

Activity

1. developer0hye

   added

   docx-corpusDOCX defect found on the docxide-pdf Word-reference corpusDOCX defect found on the docxide-pdf Word-reference corpus

   on Oct 18, 2026
2. developer0hye commented on Oct 18, 2026

   

   developer0hye

   on Oct 18, 2026

   OwnerAuthor

   More actions

   #2256 landed the flow-height part of this issue for empty frames. A body paragraph that is alone in a w:framePr frame Word lifts out of the flow, and has no content, now leaves no line. The rule follows docxide-pdf's is_empty_wrapping_frame: the frame states more than a bare w:wrap, is not yAlign="inline", is not none/notBeside, and has no w:h. Paragraphs, or a table, sharing an identical w:framePr keep their empty lines.

   Results with Word references:

   • empty-frame-control: the "Following paragraph" baseline moves from 101.17pt to 85.07pt (Word 85.03pt).
   • page-header-frame-marker: the body line is now within 0.65pt of Word, down from 10.85pt.
   • cont-first-first-fits (DOCX: paragraph after a continuous section loses about 8pt of its declared gap #2161): matches Word.

   Still open here:

   • Positioning frame content at w:x/w:y.
   • Wrapping body lines around the frame box. empty-frame-control's "paragraph" is still not at x=390.18.
   • Frames with a stated height, notBeside or none.
   • Groups of adjacent identical frames. The empty-margin-frame-* cases are unchanged; for example, empty-margin-frame-15-one-empty puts "Public greeting" at 224.81pt against Word's 213.83pt.
3. developer0hye commented on Oct 19, 2026

   

   developer0hye

   on Oct 19, 2026

   OwnerAuthor

   More actions

   #2356 (merge 3503c178) landed the second milestone of this issue: positioning frame content at w:x/w:y, for one kind of frame.

   Lifted now. A body paragraph alone in a w:framePr frame hung w:y below its place in the flow. The predicate follows docxide-pdf's Word-probed paragraph_offset_frame: w:vAnchor="text", a nonzero w:y, no w:yAlign, a stated w:w and w:h, and a w:wrap other than none/notBeside. Such a paragraph becomes a Block::TextFrame:

   • It is drawn at its frame and leaves no line in the flow. w:x/w:xAlign resolve against w:hAnchor, and the frame hangs from the end of the previous block's after-gap.
   • The root paragraphs after it wrap beside it with the float wrap from fix(docx): lay text beside a floating table instead of over it #2349 (its wider side, w:hSpace/w:vSpace).
   • A paragraph whose first line ends above the frame but which reaches it starts below the frame instead of running over it.
   • The frame keeps excluding text in a following continuous section with the same text area.

   Results against the Word references (mutool draw -F stext baselines):

   • paragraph-offset-frame-immediate: "Dear recipient" 101.97 → 85.87 (Word 85.78), "About providing information" 85.87 → 102.67 (Word 102.53). Its x stays 71pt right: the negative w:ind w:left clamp, DOCX: a negative w:ind w:left is clamped to zero, so a paragraph that hangs into the margin starts 71pt right of Word #2233.
   • paragraph-offset-frame-exact: the frame line 85.87 → 102.67 (Word 102.53). "Dear recipient" 182.36 → 166.26 (Word 146.05); the remaining 20.2pt is the empty section-mark line, DOCX: an empty section-mark paragraph's line is kept or dropped by whether its w:pPr is bare, not by its position in the section #2232.
   • paragraph-offset-frame-immediate-long: the frame is in place. The long paragraph starts at the frame's bottom edge (line 1 at 132.72, Word 85.78) instead of narrowing lines 2–3 beside it as Word does. Filed as DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355.
   • The other 21 docxide documents with a body w:framePr are unchanged. Of the nine bulk documents the rule reaches, three move toward a LibreOffice 24.2 reference, three are mixed (DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355), and three are unchanged (details in fix(docx): draw a text-anchored framed paragraph in its frame #2356).

   Still open here:

   • Both-sides line fill around an empty frame: empty-frame-control's "paragraph" at x 390.18. The wrap uses only one side; see DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355.
   • Per-line narrowing beside a lifted frame: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355.
   • Frames anchored to the page or margin, including notBeside/none, w:framePr inherited from a paragraph style, and framed tables (first-cell w:framePr). Example: docxide massachusetts_community_sanitation, whose letterhead frames push the letter about 167pt down page 1.
   • Groups of adjacent paragraphs with an identical w:framePr: the empty-margin-frame-* cases, where frames without w:vAnchor are margin-anchored per docxide's probe.
   • Frames without w:w (auto width), and text-anchored frames without w:h such as croatian_grant_guidelines'.
   • Unverified against Word: LibreOffice draws a bordered framed paragraph's w:pBdr around the whole frame box; office2pdf draws it around the paragraph only (bulk tdf133702, tdf103544).

   #2231 stays open for these.
4. developer0hye commented on Oct 20, 2026

   

   developer0hye

   on Oct 20, 2026

   OwnerAuthor

   More actions

   #2357 (merge 8d25e2d7) landed a third milestone of this issue: a group of empty framed paragraphs leaves no flow lines. CI passed on the PR and on the merge commit.

   What changed. #2256 dropped the line of an empty framed paragraph only when the paragraph was alone in its frame. Now the rule applies to the whole run of adjacent body children that share an identical w:framePr:

   • An empty paragraph leaves no line when nothing in its frame shows anything. Paragraphs holding only spaces, a hidden mark, or bookmark/comment markers count as showing nothing.
   • A frame that holds text or a table keeps its empty paragraphs' lines, as before.

   Results against Word's references ("Public greeting" baseline, pt):

   • empty-margin-frame-14-one-empty, -14-two-empty, -14-two-space-only, -hidden-marks, -off-page: 213.31–236.31 → 201.81 (Word 201.80).
   • empty-margin-frame-15-*, -visible-body-before-frame, -long-prefix (p2): the greeting now sits the right distance below the table. Both are still 12 or 24pt above Word, because Word moves the table itself down; see the first item below.
   • case128 / case130: "Below marker" 165.56 → 133.37 (Word 165.30 / 181.30). Word gives these two empty framed paragraphs no lines either. Their spurious lines had been offsetting the misplaced text-anchored floating table (DOCX: a w:tblpPr floating table with w:vertAnchor="text" is positioned from the top margin instead of its anchor paragraph #2236), whose w:clear="all" break therefore clears nothing (DOCX: w:br w:clear="all" is treated as a plain line break, so text after it stays beside a floating table instead of resuming below it #2230).
   • The corpus scan changed nothing else: no fixtures-v1 bulk document and no other docxide document moved.

   Still open here:

   • The empty frame's box.
     • Compat 15: Word keeps the group's box at the top margin, as docxide's probe has it for frames without w:vAnchor. A following full-width table moves below the box, 12pt per framed paragraph before the section mark (empty-margin-frame-15-*, visible-body-before-frame, long-prefix). Hidden marks and an off-page w:x reserve nothing.
     • Compat 14: Word does not move the table. Instead it splits the greeting line around the box: "Public" at the margin, "greeting" at x 403.17, the box's right edge. So in compat 14 the box sits on that line, not at the top margin.
     • office2pdf keeps no box for an empty frame.
   • Both-sides fill beside a frame, and per-line narrowing: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355 (empty-frame-control's "paragraph" at x 390.18).
   • Page- and margin-anchored frames, including notBeside/none; w:framePr inherited from a paragraph style; framed tables; groups that hold text. Example: docxide massachusetts_community_sanitation, page 1 about 167pt low.
     • Its "Exec Office" lines only match the title line's frame once their direct w:framePr is merged attribute by attribute over the style's, as docxide's parse_frame_props does.
     • Even with the frames lifted, the date would stay about 25pt high: Word starts it below the behindDoc wrapSquare secretary text box, which leaves no room on its right (DOCX: a wrapSquare/wrapTight anchored picture floats to the page top and the text resumes below it at full width, instead of wrapping beside it #2353 / DOCX: an anchored picture with behindDoc="1" and wp:wrapTight loses its wrap, so text runs at full width under it #2354 territory).
   • Frames without w:w (auto width), and text-anchored frames without w:h (croatian_grant_guidelines).
   • Unverified against Word: LibreOffice draws a bordered framed paragraph's w:pBdr around the whole frame box (bulk tdf133702, tdf103544).
5. developer0hye commented on Oct 20, 2026

   

   developer0hye

   on Oct 20, 2026

   OwnerAuthor

   More actions

   #2361 (merge ff37c41b) landed a fourth milestone of this issue: in compatibility mode 15, an empty frame's box at the top margin pushes a full-width table below it. CI passed on the PR and on the merge commit.

   What changed.

   • In a document that declares compatibilityMode 15 or later, a group of empty framed paragraphs still takes no flow lines. Its frame keeps a box at the top margin when the frame:
     • states no w:vAnchor (or margin);
     • has no w:y and no w:yAlign;
     • has a w:w.
   • The box has one line per visible paragraph. A hidden mark or the paragraph that ends the section adds no line, and a box wholly beside the text area is dropped.
   • A full-width table at the root of the same section that starts inside the box on its page moves to the box's bottom edge. This is checked at layout time, so it works whether the frame comes before or after the table.
   • Mode 14 and documents with no declared mode are unchanged.

   Results against Word's references (baselines, pt):

   Case	Line	Before	After	Word
   empty-margin-frame-15-two-empty	Public left	105.22	128.22	129.30
   	Public greeting	201.81	224.81	225.83
   -15-one-empty	Public left	105.22	116.72	117.28
   -visible-body-before-frame	Public left	105.22	128.22	129.30

   The remaining ~1pt is this host's Tahoma substitute, which gives the box's 10pt lines 11.50pt each against Tahoma's 12.07pt. With the Tahoma subset from Word's PDF on --font-path, "Public left" lands at 129.36. It is recorded under #1874. A scan of all 76 docxide and fixtures-v1 documents with a body w:framePr changed only these three.

   Still open here:

   • Both-sides fill beside a frame, and per-line narrowing: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355. This covers empty-frame-control's "paragraph" at x 390.18 and the compat-14 empty-margin-frame-14-* greeting, which Word splits around the box at x 403.17.
   • Rows a table carries onto the box's page. Word's empty-margin-frame-long-prefix starts them below the box (page 2, 24pt); here they still start at the top margin.
   • empty-margin-frame-15-two-space-only: its space-only paragraphs collapse (DOCX: space-only paragraphs collapse instead of reserving their line box #2288), so its box has no height.
   • Unprobed box rules. Only full-width tables and frames at the top margin itself (no w:y/w:yAlign) have Word references. Narrower tables and offset or aligned margin frames are left alone.
   • Page- and margin-anchored frames with content, including notBeside/none; w:framePr inherited from a paragraph style; framed tables; groups that hold text. Example: docxide massachusetts_community_sanitation, page 1 about 167pt low.
   • Frames without w:w (auto width), and text-anchored frames without w:h (croatian_grant_guidelines).
   • Unverified against Word: LibreOffice draws a bordered framed paragraph's w:pBdr around the whole frame box (bulk tdf133702, tdf103544).
6. developer0hye commented on Oct 20, 2026

   

   developer0hye

   on Oct 20, 2026

   OwnerAuthor

   More actions

   #2362 (merge 6d02d1e8) landed a fifth milestone of this issue: rows a table carries onto the page of an empty frame's top-margin box now start below the box. CI passed on the PR and on the merge commit.

   What changed.

   • In compatibility mode 15, a full-width root table in a box's section, directly followed by the box's empty frame group, now carries labels on its first and last pages.
   • On a page the table reaches from an earlier one, the box floats at the top of the page. The carried rows, and everything after them, start below it. Elsewhere the box takes no flow space, as before.
   • The float is laid only when the carried rows still end on that page below the box. Otherwise the float would move them, the group and the box on to the next page, and Typst's layout would not settle. In that case the rows keep their place (a TODO; no Word reference shows it).

   Results against Word's reference (empty-margin-frame-long-prefix, baselines, pt):

   Line	Before	After	Word
   Page 1 "Public left"	105.22	105.22	105.28
   Page 2 first "Public recipient"	105.22	128.22	129.30
   Page 2 "Public greeting"	620.38	643.37	644.70

   The remaining ~1pt is the host's Tahoma substitute again: with Word's embedded Tahoma subset on --font-path, page 2 starts at 129.36 and the greeting sits at 644.52. It is recorded under #1874. A scan of every docxide, fixtures-v1 and tracked document with a w:framePr changed only this case and its tracked copy.

   Still open here:

   • Both-sides fill beside a frame, and per-line narrowing: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355. This covers empty-frame-control's "paragraph" at x 390.18 and the compat-14 empty-margin-frame-14-* greeting, which Word splits around the box at x 403.17.
   • empty-margin-frame-15-two-space-only: its space-only paragraphs collapse (DOCX: space-only paragraphs collapse instead of reserving their line box #2288), so its box has no height.
   • Unprobed box rules. Only full-width tables, and boxes at the top margin itself (no w:y/w:yAlign), have Word references. Narrower tables, offset or aligned margin frames, content between the table and the group, and carried rows the box would push onto the next page are left alone.
   • Page- and margin-anchored frames with content, including notBeside/none; w:framePr inherited from a paragraph style; framed tables; groups that hold text. Example: docxide massachusetts_community_sanitation, page 1 about 167pt low.
   • Frames without w:w (auto width), and text-anchored frames without w:h (croatian_grant_guidelines).
   • Unverified against Word: LibreOffice draws a bordered framed paragraph's w:pBdr around the whole frame box (bulk tdf133702, tdf103544).
7. developer0hye commented on Oct 20, 2026

   

   developer0hye

   on Oct 20, 2026

   OwnerAuthor

   More actions

   #2365 (merge d041a66e) landed a sixth milestone of this issue: a frame Word keeps at a fixed place on its page and keeps text off the sides of is drawn at that place, and the body text it meets starts below it. CI passed on the PR and on the merge commit.

   What changed.

   • Effective frame. A body child's w:framePr is now its paragraph style's (nearest w:basedOn ancestor stating one), with each attribute the paragraph states over it. A table's is its first cell paragraph's. A frame stating only w:wrap is no frame. The existing empty-frame, offset-frame and top-margin-box rules use the same effective frame.
   • Fixed frames. Adjacent children sharing a frame with w:vAnchor page or margin/none, w:wrap notBeside/none and no w:yAlign become one TextFrame (text_below), drawn at its page position.
   • Band. Root paragraphs after it on its page whose first line meets its band start below it. The float wrap now re-checks until a pass moves the line no further, so overlapping bands chain.
   • Kept in the flow: a frame that shows only spaces (an existing test pins it), and a frame holding lists, breaks or drawings.

   Results against Word's reference of docxide-pdf's scraped massachusetts_community_sanitation (page 1, x and baseline, pt):

   Line	Before	After	Word
   "The Commonwealth of Massachusetts"	168.28, 153.75	194.08, 31.25	193.83, 31.00
   Seal picture	in the flow	45.30, 13.10	45.25, 13.05
   "CHARLES D. BAKER"	61.41, 297.98	37.86, 135.89	35.52, 134.30
   "May 28, 2021"	394.48	232.39	227.08

   The date's 5.3pt is two residuals nearly cancelling, each now tracked:

   • The governor block's Arial Rounded MT Bold has no stand-in here, so its lines spread (Fonts: Arial Rounded MT Bold, absent from the host and the substitution table, paints in the serif default and its paragraphs get no Word line box #2363). With Word's embedded subset they match within 0.02pt, and the date sits 26.1pt high.
   • That 26.1pt is the behindDoc wrapSquare secretary text box the letter should start below (DOCX: an anchored picture with behindDoc="1" and wp:wrapTight loses its wrap, so text runs at full width under it #2354). Its own lines are about 8pt high (DOCX: top-aligned caption text crosses its textbox upper border #2314).
   • The EMF signature is dropped (DOCX: an inline EMF holding one 32-bpp EMR_STRETCHDIBITS bitmap is dropped, so a signature picture paints nothing and takes no space #2364).
   • Pages 2–15 are reflow from page 1: constant offsets at Word's pitch.

   A corpus scan of 2,366 DOCX moved only that document and six bulk LibreOffice frame documents, all toward a LibreOffice 24.2 reference (labelled non-Word; details in #2365).

   Struck from the list: croatian_grant_guidelines' text-anchored frame without w:h. Word keeps it in the flow, as office2pdf does; only its w:x="-39" (1.95pt) shift differs, which is sub-material and recorded in #1874.

   Still open here:

   • Both-sides fill beside a frame, and per-line narrowing: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355.
   • empty-margin-frame-15-two-space-only: DOCX: space-only paragraphs collapse instead of reserving their line box #2288.
   • Unprobed top-margin box rules (narrower tables, offset or aligned margin frames, content between the table and the group).
   • Fixed frames, remaining parts:
     • Auto width. A frame without w:w lays its paragraphs across the text width from its left edge (FIXME). Word sizes it to the widest line, which matters for centred or right-aligned lines.
     • Frames that stay in the flow: those placed by w:yAlign or by w:xAlign without w:w; those inside block-level w:sdt (bulk tdf148671, three of six); and those holding lists or drawings (bulk Tdf147485).
     • Band gaps. Body text before the frame and tables after it do not clear its band. A band reaching the page's end does not move the next paragraph to the next page (bulk tdf104394_lostTextbox).
   • Page- or margin-anchored frames with content that wrap around (auto/around), which still flow.
   • Unverified against Word: LibreOffice draws a bordered framed paragraph's w:pBdr around the whole frame box (bulk tdf133702, tdf103544, tdf100075).
8. developer0hye commented on Oct 20, 2026

   

   developer0hye

   on Oct 20, 2026

   OwnerAuthor

   More actions

   Draft #2368: frames inside block-level content controls. Not merged: its only reference is LibreOffice, and this Linux host cannot export from Word. CI passes on the draft, the Visual PR Contract included.

   What #2368 does. A paragraph or table inside a block w:sdt now has its w:framePr frame laid out as it would be without the control. Body children are flattened into flow children, each control expanding into its paragraphs and tables. Every existing frame rule groups and places frames by flow index: fixed page frames, offset frames, empty frames and the compat-15 top-margin box. A test pins it for five frame kinds, in single and nested controls. In bulk tdf148671, the three controlled page frames move from the flow at the top left (x 35.45) to their frame places (x 434.30), within 1.1pt of a LibreOffice 24.2 export (LibreOffice reference, not Word). The remaining 1.1pt is the two sides' different substitutes for Microsoft Sans Serif. A scan of all 2,366 DOCX packages (docxide-pdf, fixtures-v1, tracked) changed only that file.

   To merge #2368, a Mac must: export tests/fixtures/docx/libreoffice/tdf148671.docx from Word to PDF and confirm the three controlled frames sit at x 434.3pt with their tops at y 183.05, 198.05 and 212.3pt. Then regenerate the PR's gt.jpg, layout-audit.json and render-clusters-page-1.json from that PDF. The steps are in the PR body.

   Re-audit, so the next session need not repeat it. All 22 framed docxide-pdf cases and the scraped massachusetts letter were measured again on main d041a66e against their Word references. Every remaining deviation already has another open issue: #2355 (both-sides and per-line wrap), #2288 (-15-two-space-only), #2233 (negative indent of the offset frame text), #2232 (paragraph-offset-frame-exact section mark), #2236/#2230 (case116/128/130), #2253–#2255 (cont-first-*-overflow), #2363, #2354, #2364 and #2314 (massachusetts).

   Struck from the list: auto width. With Word's embedded Arial Rounded MT Bold subset on --font-path, massachusetts' auto-width, centred governor frame matches Word within 0.2pt on three of its four lines. The fourth, "Lieutenant Governor", is 2.17pt left because its trailing spaces are centred (sub-material, recorded in #1874). No Word reference shows an auto-width defect, so the FIXME(auto frame width) stays unverified rather than open work.

   Filed while auditing: the vertical rule in tdf148671 gets arrowheads from its type-less a:headEnd/a:tailEnd (#2366), and its schemeClr stroke paints black instead of grey (#2367).

   Still open here. Every item needs a Word export or a one-factor probe, so this issue is labelled autofix-blocked:

   • Frames in block content controls: draft fix(docx): lay out frames in block content controls like body frames #2368, waiting for the Word export of tdf148671 described above.
   • Band gaps around fixed frames: body text before the frame, tables after it, and a band reaching the page's end. Needs a Word PDF of bulk tdf104394_lostTextbox, whose last paragraph says it is "Pushed to page 2 by the framed text". That file also holds a w:yAlign="top" frame, which stays in the flow here.
   • Lists and drawings in a fixed frame: a Word PDF of bulk Tdf147485.
   • A framed paragraph's w:pBdr drawn around the whole frame box: Word PDFs of bulk tdf133702, tdf103544 and tdf100075.
   • Top-margin box variants (narrower tables, offset or aligned margin frames, content between the table and the group), and page- or margin-anchored around/auto frames with body text beside them. No corpus document isolates these, so each needs a one-factor scripts/probe_harness.py probe exported from Word.
   • Both-sides fill and per-line narrowing: DOCX: a paragraph that reaches a lifted w:framePr text frame starts below it instead of narrowing only the lines beside it #2355. empty-margin-frame-15-two-space-only: DOCX: space-only paragraphs collapse instead of reserving their line box #2288.

   The candidate and base binaries, the evidence PDFs and the timing runs for #2368 are kept on the host that ran this (/tmp/i2231). The corpus checkouts and build targets were removed.
9. developer0hye

   added

   autofix-blockedissue-loop: unattended attempts failed, needs human reviewissue-loop: unattended attempts failed, needs human review

   on Oct 20, 2026