[DemchaAV]

Why

The page draws a picture contained in its box (fitToBounds, CONTAIN) in the box's middle
(PdfImageFragmentRenderHandler). The DOCX export embedded it at its fitted size and nothing else,
so the room it leaves in the box was lost.

Measured in Word 16 and LibreOffice on Windows, a 200×100 picture fitted to a 100pt square:

	Page	Before, in Word / LibreOffice	After, in Word / LibreOffice
picture	y 110–160	y 85–135 / 84.9–134.9	y 110–160 / 109.9–159.9
the paragraph under it, baseline	199.2	148.2 / 148.3	198.0 / 198.0

Nothing was named. The point left over on the paragraph under it is Word's own: "Before", above
the picture, stands 0.9pt higher too.

What changed

• roomRound: the room a contained picture leaves round it in its box, half on either side, as
  the page centres it. The fitted size comes from containedIn, which addFittedPicture now uses
  too.
• writeImage:
  • The room above and below is passed to applyVerticalSpacing, with the picture's margin and
    padding, so a pull from the block before comes out of it as out of them.
  • The room at the side goes on the paragraph's indent (holdInAcross), on top of the insets
    that hold the box in.
  • In a band, the space owed below is the band's, measured from the picture's box, which holds the
    room below. There the room below is written as the paragraph's own space after.
• Docs:
  • the recipe's images row;
  • the capability matrix's image row;
  • the writeImage Javadoc;
  • CHANGELOG v2.5.0.

Verification

• Further cases in Word and LibreOffice, after the change:
  • a 100×200 picture in a 100pt square: x 97–147, as the page;
  • one centred by addAligned: x 175–225, as the page;
  • one in a row's cell: y 110–160, as the page.
  • In a band, under a heading: the layer stands 12.95pt lower than the page sets it, which is
    named (overlapping layer), and the paragraph under the band follows it by that much (12pt).
• Corpus, 62 DOCX before and after: all 62 are byte-identical, and the report's 1246 notes are
  identical.
• Example: word-export-companion.docx was regenerated. It differs from the committed one only
  in docProps/core.xml, the export's time.
• DocxContainedPictureTest (new, 8 tests):
  • a wide picture, the room above and below;
  • a tall one, the room at its side;
  • one that fits its box, and one stretched, unchanged;
  • in a row's cell, the room above and the room below paid there;
  • composed in a table's cell;
  • centred by an alignment;
  • in a band, the room below its own.
• 7 sabotages, all caught:
  • no room;
  • no room above;
  • no room below;
  • none at the side;
  • the whole room above;
  • every fit mode;
  • a band's room below owed rather than its own.
• ./mvnw -B -ntp clean verify: BUILD SUCCESS (core 821, render-docx 1849, examples 93, qa 1820).
  The knowledge pack's --check passes.

Two things this leaves as they were, each a separate step:

• At the top of a page, Word drops a paragraph's space above. A contained picture the layout
  moves to a new page stands 25pt high in both editors, as its margin above already did.
• Composed in a table's cell, the page draws the picture as wide as the cell, 112pt in a 120pt
  column, while Word holds it to its 100pt bounds.

Lane: render-docx (semantic backend). DOCX output changes only for a picture contained in a box
it does not fill.