[DemchaAV]

Why

A layer stack whose layers overlap is written as a band: its layers one after the other, with the page's space above and below the band. Where a painted section opens or closes the band, as a card under an icon laid over its corner does, that space is measured through the card's padding, which the card writes again inside its cell. Measured in Word 16 and LibreOffice, the export sets such a card and everything under it lower than the page, and leaves the icon where the page draws it, so it no longer stands on the card's corner and does not move when text above the card is edited.

The changes that anchor a drawing in its owner's paragraph and keep such a stack where the page sets it need a document built to show it, held by the fidelity gate in both editors: each such change then moves its lines nearer the page, and no change can move them further unnoticed. No document of the corpus has one. Searched over the 70 documents' layout: no layer stack or shape container lays a drawing on a painted layer holding text, and no band is opened or closed by a painted section holding text.

What changed

• SyntheticDocxCorpus takes icon_over_card: a layer stack laying an 18pt icon over the top right corner of a card — a section painted as a panel with 14pt padding, holding one paragraph — between a paragraph above it and one under it, on a page 400 × 500pt, text in Lato, which the export embeds. The paragraph above is the document's longest, so the editing protocol's drawings-follow-text, which lengthens the longest paragraph, moves the card and checks the icon moves with it.
• Baselines. word-windows and libreoffice-windows take the document's rows alone, from the runs below; every other row stays as recorded. libreoffice-linux takes them from this PR's CI run (artifact docx-fidelity-40477924801), where the DOCX Fidelity job failed on this document alone, not yet in the baseline. A comment under each file's header says where the rows were measured.
  • The rows record the export as it stands: the card's two lines 14pt lower than the page, and the paragraph under it 28pt lower. A change that writes the band's space from the card's edges moves them nearer the page and rewrites the rows with -Dgraphcompose.docxFidelity.update=true.
• Docs:
  • the DOCX recipe said a band keeps the page's distances above and below it; it now says that space is measured to the band's first and last block written, through a panel among the layers, so a panel opening or closing the band writes inside its cell padding the band's space already holds, and that the corpus holds this case's lines but not where its icon stands. The passage on a shape the nearest paragraph cannot carry names an icon over a panel's top corner as one;
  • CONTRIBUTING.md: an icon a layer stack lays over a card's corner joins the examples of a shape SyntheticDocxCorpus holds;
  • the CHANGELOG's Tests entry.

Measured

Lines found of the page's, then the drift of the found lines (pt; positive is low):

Line	Word 16 (16.0.20527)	LibreOffice 24.2 (Linux, CI)	LibreOffice 26.8 (Windows)
found	6/6	6/6	6/6
paragraph above (3 lines)	−0.01	−0.02	−0.02
card's two lines	+13.99	+13.98 (and 14.10 right)	+13.98
paragraph under the card	+28.02	+27.98	+27.98

• Where the space comes from. The paragraph above the card is written with 22pt after it — the page's 8pt between blocks and the card's 14pt top padding — and the paragraph under it with 22pt before it, the page's 8pt and the card's 14pt bottom padding. The card's cell holds the same padding as its margins. The band takes its space above to its first block written and below from its last (DocxLayerColumns.band), the card's paragraph, and the card's padding lies between it and the band's edges.
• The control (a probe on A4 in Helvetica, the same card and icon). The card alone in the flow, and alone in a stack of one layer — which is not a band — stand where the page sets them in Word, every line within 0.3pt. With the icon at the card's bottom left corner instead, anchored in a paragraph that moves it with the card, the card and the paragraph under it stand 14 and 28pt low as here.
• The icon is drawn from the page's edges, at the page's place: the card's text starts 14pt below its top, more than a shape may rise above a cell's paragraph, and the paragraph that is nearest cannot carry it, so no paragraph does. Both editors draw it where the page does, 14pt above the card's top as they set it. Word's editing protocol (edit-protocol-corpus.ps1, drawings-follow-text), lengthening the paragraph above the card, moves the card 36pt and the icon not at all, and fails.
• LibreOffice 24.2 also sets the card's text 14.1pt right of the page, reading the table's indent as its edge, as it sets the card alone; the Linux rows hold that too, since the gate holds a line's drift across as well as down.

Tests

• Word: scripts/docx-visual/word-fidelity.ps1 (Word 16.0.20527) → the corpus test in word mode passes on all 71 documents against the extended word-windows. Before the rows were added, it failed on the new document alone, as not in the baseline.
• LibreOffice, Windows: -Dgraphcompose.docxFidelity=libreoffice → the new document passes against the extended libreoffice-windows. invoice-obsidian and proposal-indigo fail as they do on 2.5-dev (named in test(qa): hold the ways a page breaks inside a panel in the DOCX fidelity corpus #965): this change exports both byte for byte as 2.5-dev does.
• CI, LibreOffice 24.2 (Linux): the first run (40477924801) failed on the new document alone, as not in the baseline, measuring it as LibreOffice 24.2 did locally (docker); the third commit takes those rows, and on it DOCX Fidelity (LibreOffice) passes (run 40483012285).
• The gate holds the rows (sabotages). Each sabotage alone, then the gate it should fail; every one caught, the files byte-identical afterwards:
  • the Word baseline without the document's rows: the Word gate fails it, as not in the baseline;
  • the Word baseline holding the paragraph under the card at +27.02pt, and the card's first line at +12.99pt: the Word gate fails each, the line 1pt further from the page than its row;
  • the Windows LibreOffice baseline without the document's rows: the LibreOffice gate fails it;
  • the export writing every band's space above 2pt taller (DocxLayerColumns.band), installed: the Word gate fails the document, its card's two lines and the paragraph under it each 2pt further from the page, with the 15 presets that set a band (cv-serif_headline, invoice-payments, proposal-northline among them).
• Corpus: 71 documents exported; the 70 already in the corpus byte-identical to 2.5-dev; the report's notes 1498 → 1499, the one added on the new document.
• clean verify of the reactor as CI runs it → BUILD SUCCESS (core 823, render-pdf 339, render-docx 2311, testing 5, render-pptx 142, templates 127, qa 1846); the four knowledge checks and core javadoc (0 warnings) pass; examples 93.

Named, not fixed

• The gate measures lines of text. Where the icon stands — on the card's corner or above it — it does not see, nor whether it follows the card when text above is edited; Word's editing protocol does, and fails the document.
• The document's paragraph above the card is the longest, so the protocol edits it. Lengthened inside the card instead, the edit moves nothing above the card, and the protocol would pass the icon whether it follows the card or not.

Lane: tests (qa) and documentation. No public API change, and no change to the export.