test

[artem-harbour]

No description provided.

[github-actions]

The ecma-spec MCP tools are consistently blocked by permissions in this environment (every call returns "permission not granted"), and I can't prompt for access either. I've verified the handlers against my knowledge of ECMA-376 instead, and I'm noting where live spec confirmation wasn't possible.

---

Status: PASS

I reviewed the six changed OOXML handler files. The DrawingML and VML elements/attributes they read and write are all legitimate and used correctly. No non-existent elements/attributes, no spec violations.

⚠️ Caveat: the ecma-spec MCP tools returned "permission not granted" on every call, so this is a knowledge-based review rather than one verified against the live ECMA-376 schema. The items below reflect standard OOXML semantics.

What I checked, and why each is sound:

• import-drawingml-textbox.js / encode-image-node-helpers.js — Reads wps:wsp → wps:cNvSpPr@txBox, wps:txbx → w:txbxContent, and wps:bodyPr. These are the correct WordprocessingShape (wps) structures for a DrawingML text box, and txbxContent is the right WML element. The bodyPr@anchor='ctr' → 'center' mapping matches ST_TextAnchoringType (t/ctr/b/just/dist). Inset conversion (91440 EMU → 9.6px, 45720 → 4.8px) is correct (914400 EMU/in, 96px/in). See https://ooxml.dev/spec?q=bodyPr

• translate-drawingml-textbox.js — Exports mc:AlternateContent → mc:Choice Requires="wps" wrapping the replayed w:drawing. This matches how Word emits DrawingML shapes, and Requires taking a namespace-prefix token is correct per Markup Compatibility. See https://ooxml.dev/spec?q=AlternateContent

• handle-shape-textbox-import.js / translate-shape-container.js — VML round-trip via v:shape style with mso-position-horizontal[-relative], mso-position-vertical[-relative], margin-left/top, plus v:textbox and w10:wrap. These are valid VML/office-CSS positioning properties (Part 4 Transitional), and the export mirrors the import. The v:shape@type (e.g. #_x0000_t202) is preserved via ...node.attrs.attributes. pt↔px conversions are correct. See https://ooxml.dev/spec?q=shape

• r-translator.js — Block-hoisting of shapeContainer out of a run is an internal PM-model concern, not an OOXML serialization path, so no spec surface to violate.

Minor robustness note (not a spec violation):

• encode-image-node-helpers.js (and the textbox detection in getVectorShape) gate on cNvSpPr.attributes['txBox'] === '1'. txBox is xsd:boolean, which also permits "true". Word always writes "1", so this is fine in practice, but a stricter check would also accept "true".

I'd suggest re-running the ecma-spec lookups once the MCP permission is enabled if you want the schema-level confirmation on a:CT_TextBodyProperties, a:CT_NonVisualDrawingShapeProps@txBox, and mc:Choice@Requires.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!