test

[artem-harbour]

No description provided.

[github-actions]

The ecma-spec MCP tools are being denied permission in this session (I tried several times — read-only lookups for wp:extent, a:ext, and posOffset), so I verified the OOXML usage against ECMA-376 from knowledge rather than the live spec tools. Flagging that up front so you know the spec citations weren't machine-confirmed this run.

Scoping to the two handler files that actually emit OOXML (translate-shape-container.js, translate-drawingml-textbox.js); the rest of the diff is Vue/layout-engine UI and tests.

Status: PASS

Here's what I checked and why each is sound:

translate-drawingml-textbox.js — patches geometry/position on export:

• wp:extent and a:ext both get cx/cy patched. Both are CT_PositiveSize2D, where cx/cy are required — and the code only mutates attributes on elements that already exist in the source tree (it never creates a partial element), so the required-attribute invariant is preserved. The "only width changed" path patches cx and leaves cy intact, which is correct. (wp:extent, a:ext)
• wp:posOffset is patched as text content in EMU, and only when a wp:posOffset already exists (absolute positioning) — it correctly avoids touching wp:align-based positioning. ST_PositionOffset is a signed int, so negative offsets from a drag are valid. (wp:posOffset)
• The wps:spPr > a:xfrm > a:ext path navigation is the correct WordprocessingShape structure, and switching from DFS-first-match to an explicit path is actually a real fix — the old DFS could hit an a:ext in an a:extLst extension list (which carries uri, not cx/cy). The test guards exactly this.
• EMU conversion (pixelsToEmu, 9525 EMU/px = 914400/96) is correct.

translate-shape-container.js — VML w:pict shape:

• Adds width/height in pt to the VML shape style string. VML shape styling is freeform CSS-like, and width/height with pt units are valid there. No spec issue.

No non-existent elements/attributes, no dropped required attributes, no wrong defaults, and sizes are clamped positive upstream (min 20px) so the CT_PositiveSize2D positivity constraint holds.

One non-blocking note (not a spec violation): on a rotated shape, wp:extent (the rendered bounding box) and a:ext (the unrotated shape geometry) legitimately differ, but the code writes the same value to both. Resize on a rotated textbox could therefore write a slightly off wp:extent. Worth a follow-up if rotated textbox resize is in scope, but it doesn't violate the schema.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!