fix(super-editor): emit OOXML property children in canonical schema order

[dbrogan-OSI]

Problem

OOXML property containers — w:rPr, w:pPr, w:numPr, w:trPr, w:tcPr, w:tblPr, w:tblPrEx, w:sectPr — are defined by ECMA-376 as xsd:sequence complex types (CT_RPr, CT_PPr, CT_NumPr, …). Their child elements must appear in a fixed schema order.

On export, SuperDoc emits these children in JavaScript insertion order:

• decodeProperties() (v3/handlers/utils.js) iterates Object.keys(attrs), i.e. ProseMirror attribute insertion order.
• generateRunProps() (exporter.js) emits run marks in mark-array order.

Neither matches the schema sequence, so children are emitted in arbitrary order: w:numId before w:ilvl on every list item, w:color before w:rFonts, w:trPr w:hidden before w:trHeight, w:tblPr w:tblLook before w:tblCellMar, etc.

Why this is easy to miss

Desktop Word silently repairs out-of-order children on open, so the document looks fine there. Word for the web rejects the package and opens the document read-only as "corrupt." We hit this repeatedly against real exports — it is the cause of "document opens read-only in Word for the web."

Before / after (a list item)

Before (rejected by Word online):

<w:numPr>
  <w:numId w:val="3"/>
  <w:ilvl w:val="0"/>
</w:numPr>

After (canonical CT_NumPr order):

<w:numPr>
  <w:ilvl w:val="0"/>
  <w:numId w:val="3"/>
</w:numPr>

Fix

Add a shared canonical child-order table keyed by container local name (v3/handlers/ooxml-property-order.js) and stable-sort the emitted children at the two emit sites:

• createNestedPropertiesTranslator.decode in utils.js — covers w:rPr, w:pPr, w:numPr, w:trPr, w:tcPr, w:tblPr.
• generateRunProps in exporter.js — the run-mark w:rPr path that bypasses the v3 translator.

Unknown/extension elements (w14:*, mc:AlternateContent) sort after all known children with their relative order preserved (stable). Containers without a canonical sequence are returned unchanged.

This generalizes the existing CT_TC_MAR_CHILD_ORDER pattern (tcMar/tblCellMar) into one reusable table rather than per-container wrappers.

w:sectPr and w:tblPrEx sequences are included in the table for completeness; their emission currently runs through separate v2 paths, so wiring those is a ready follow-up.

Tests

• New ooxml-property-order.test.js: utility unit tests for all wired containers + integration through real w:numPr, w:trPr, and w:rPr translators (13 tests).
• All existing converter/exporter suites pass.

Test plan

• pnpm --filter super-editor test for the changed converter/exporter tests
• Open an exported list/table doc in Word for the web and confirm it is no longer read-only / flagged corrupt

Made with Cursor

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3415911db0

ℹ️ 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".

[chatgpt-codex-connector]

Preserve paragraph rPr track-change order

When w:rPr is the paragraph-mark run properties under w:pPr, the same rPr translator can emit trackInsert/trackDelete as w:ins/w:del; those children belong before the normal run-property sequence for CT_ParaRPr. Because this new order table omits them, the sorter treats them as unknown and moves them after known props, so a valid tracked paragraph mark such as <w:rPr><w:ins/><w:b/></w:rPr> round-trips as <w:b/><w:ins/>, which violates the fixed OOXML sequence and can still make Word reject the document.

Useful? React with 👍 / 👎.