fix: rendering and text alignment for textboxes with table content

[VladaHarbour]

No description provided.

[linear-code]

SD-2745

[github-actions]

I wasn't able to run the ecma-spec MCP tools — the environment didn't grant permission for them (I retried; each call returned a pending-permission error). So this review is based on ECMA-376 knowledge rather than live spec lookups. Flagging that up front for transparency.

Here's my review of the two changed handler files.

Status: PASS

Everything these handlers read and emit lines up with ECMA-376. Details:

encode-image-node-helpers.js

• behindDoc is a real attribute of wp:anchor (CT_Anchor) — a boolean defaulting to false. The new isBehindDoc check ('1' | 1 | true) and hasBehindDocAttribute guard are correct. Reading it as "1" is right.
• Preserving behindDoc for non-None wrap types (Square/Tight/etc.) is spec-faithful: behindDoc lives on the anchor and applies regardless of the wrap mode, so it's not a None-only concept. No violation. https://ooxml.dev/spec?q=anchor

textbox-content-helpers.js

• Elements read — w:tbl, w:tr, w:tc, w:tcPr, w:tcW, w:tblGrid, w:gridCol — are all valid, and the w:w attribute on w:gridCol/w:tcW is correct.
• createTabRun() emits w:r > w:tab (the tab character, CT_Empty) — valid run content, no attributes required.
• createTabStop() emits w:tab inside w:tabs (the tab stop, CT_TabStop). Both required attributes are present: w:val (ST_TabJc) and w:pos (ST_SignedTwipsMeasure). The default 'left' is a valid ST_TabJc value. Note these are two distinct w:tab elements in the spec sharing a name in different contexts — the code uses each correctly. https://ooxml.dev/spec?q=tab

One non-blocking observation (not failing the review): buildVisualLineParagraphProperties appends the synthesized w:tabs to the end of w:pPr.elements, after existing children like w:spacing. In the CT_PPr schema sequence w:tabs precedes w:spacing, so the emitted ordering is technically out of sequence. It doesn't break anything here because these nodes are an intermediate parse tree consumed by the import converter (read by name, not serialized to a .docx), so I'm not failing on it — but if any of this output ever gets written back to OOXML, the ordering would want fixing.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b7ffcb41bc

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[superdoc-bot]

This pull request landed on main as 89c92e6.

[superdoc-bot]

🎉 This PR is included in superdoc-cli v0.17.0

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in superdoc-sdk v1.16.0

[superdoc-bot]

🎉 This PR is included in @superdoc-dev/mcp v0.12.0

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in superdoc v1.40.0

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in @superdoc-dev/react v1.11.0

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in vscode-ext v2.12.0