Shapes inside mc:AlternateContent are never rendered

[mantissaman]

Split out of #3.

Shapes wrapped in mc:AlternateContent are never drawn. They survive a load and save because we keep unknown XML verbatim, but the layout engine never sees them, so nothing is rendered and no space is reserved.

Cause

Word writes a shape as a compatibility block. The modern DrawingML version goes in mc:Choice and a VML fallback goes in mc:Fallback:

<mc:AlternateContent>
  <mc:Choice Requires="wps"><w:drawing>...</w:drawing></mc:Choice>
  <mc:Fallback><w:pict><v:shape .../></w:pict></mc:Fallback>
</mc:AlternateContent>

CT_R::from_xml knows about w:drawing but not about mc:AlternateContent, so the whole block falls into the unknown element branch and is captured as raw XML. The w:drawing inside it is never parsed into a RunContent::Drawing, so it never reaches layout.

In the file attached to #3 there are five of these, and every one of them is invisible in our output.

Fix

Handle mc:AlternateContent in the run parser. Descend into mc:Choice when we support what it requires, and fall back to mc:Fallback otherwise. Keeping the raw copy for write back is still fine, the point is to also parse the content so layout can use it.

Rendering the shape geometry itself is a separate and larger job. This issue is only about the drawing inside mc:Choice becoming visible to layout, which also fixes the reserved space.

[mantissaman]

Correcting this issue. I went to implement it and the fix I described above would not have worked.

What these shapes actually are

I pulled apart the five blocks in the file attached to #3:

shape	position	size	geometry	fill
1	H column 3.16in, V paragraph 0.15in	1.74 x 0.80in	rect	729fcf, 3465a4
2	H column 0.40in, V paragraph 0.15in	1.74 x 0.80in	rect	729fcf, 3465a4
3	H column 3.27in, V paragraph -0.03in	1.52 x 0.53in	rect	none
4	H column 0.50in, V paragraph -0.04in	1.51 x 0.56in	rect	none
5	H column 2.14in, V paragraph -0.08in	1.02 x 0.00in	line	3465a4

They are wps:wsp shapes, mc:Choice Requires="wps". There is no a:blip and no text anywhere in them. So parsing the w:drawing inside mc:Choice, which is what I originally proposed, produces a drawing with nothing drawable in it. Nothing would appear on the page.

What is actually needed

Three pieces, and only the first one is what this issue originally described.

1. Parse mc:AlternateContent so the DrawingML in mc:Choice reaches the model. The raw copy has to stay for write back so the mc:Fallback is not lost, which means the parsed form must not be serialised again or the element ends up duplicated.
2. Model and render the shape itself. Preset geometry, solid fill and outline. PositionedElement::FilledRect already exists and both backends support it, so a rect preset is reachable. line needs the existing Line element. Anything beyond those two presets is a bigger job.
3. Correct anchor positioning, which is Anchored images ignore relativeFrom and land in the page corner #10.

This is blocked on #10

Every one of these shapes is positioned relativeFrom="column" horizontally and relativeFrom="paragraph" vertically, with offsets that only mean anything relative to those frames. That is the same code path as #10, where we treat the offset as an absolute page coordinate.

So doing 1 and 2 without 3 would draw all five shapes stacked near the page origin instead of beside their paragraphs. That is not an improvement on drawing nothing, and it would have to be redone once #10 lands.

Leaving this open and blocked on #10. Worth noting that #10 is in the function PR #2 is rewriting, so the ordering is PR #2, then #10, then this.

[mantissaman]

Correcting myself again, and this time the correction matters for how the work is scoped.

My comment above said there is no text anywhere in these shapes. That is wrong. I checked the first mc:AlternateContent block and generalised to all five. Two of them do carry text.

What the five shapes actually are

shape	geometry	fill	outline	text
1	rect	729fcf / 3465a4	yes	none
2	rect	729fcf / 3465a4	yes	none
3	rect	<a:noFill/>	<a:ln w="0"><a:noFill/></a:ln>	"Very important text inside a box"
4	rect	<a:noFill/>	<a:ln w="0"><a:noFill/></a:ln>	"Very important drawing"
5	line	3465a4	yes	none

So this is a small diagram. Shapes 1 and 2 are the coloured boxes, 3 and 4 are invisible rectangles holding the labels that sit on top of them, and 5 is the connector between them.

Why that changes the work

Shapes 3 and 4 have no fill and no outline. Their only visible content is their text, which lives in wps:txbx as ordinary w:p paragraphs. So rendering geometry and fill alone would draw two coloured boxes and a line with no labels on them, which is a worse result than drawing nothing at all for a document like this one.

Three separable pieces, in dependency order:

1. Parse mc:AlternateContent so the DrawingML in mc:Choice reaches the model. The raw copy has to stay for write back so the mc:Fallback survives, which means the parsed form must not be serialised again or the element is duplicated. Both of the pieces below need this.
2. Geometry and fill. PositionedElement::FilledRect covers a rect preset and Line covers the line preset, so shapes 1, 2 and 5 are reachable once positioning works. noFill shapes correctly draw nothing.
3. Text boxes. Lay out the w:txbxContent paragraphs at the shape width and render them at the shape position. render_hf_blocks already renders pre-laid-out paragraphs at an arbitrary y, so the pattern exists, but it is pinned to the left margin and would need an x offset.

Positioning itself is no longer a blocker. #10 is fixed and on main, so resolve_anchor_h and resolve_anchor_v handle the column and paragraph frames these shapes use.

I am going to leave this open rather than half implement it. Doing 1 and 2 without 3 makes this specific document look broken, and 3 is the larger part.