fix: only include inline pPr on export

[VladaHarbour]

Exclude inherited props from document.xml on export

[linear]

SD-1919 Exporter bakes resolved styles as inline properties

[github-actions]

Status: FAIL

The overall approach is sound — tracking inline keys to suppress redundant w:rPr/w:tcPr output on export is exactly what the spec calls for (§17.4.68, §17.3.1.29), and the w:pPr/w:rPr, w:tcMar, and omitted-w:rPr behaviors are all spec-compliant. One bug stands out:

---

Style-inheritance merge order is reversed — run-properties-export.js:35–47

// chain is built: [derivedStyle_rPr, baseStyle_rPr, grandbaseStyle_rPr, ...]
chain.forEach((rPr) => {
  (rPr.elements || []).forEach((el) => {
    if (el?.name) byName[el.name] = el;  // last write wins
  });
});

The comment says "base first, then derived (later overrides by element name)" — which correctly describes OOXML cascade semantics — but the chain is populated derived-first (the while-loop starts at styleId and walks up via basedOn). Since forEach overwrites, the last item in the chain wins, and the last item is the base style. So base properties overwrite derived ones, inverting the cascade.

OOXML §17.7 is clear that a derived character style overrides its base. With the merge backwards, when a derived style changes a property that its base also defines (say w:b or w:sz), getParagraphStyleRunPropertiesFromStylesXml returns the base style's value for that property. The export filter then sees runProperties[key] !== styleVal (using the wrong base value) and may incorrectly emit or suppress the property — ultimately producing a w:rPr that doesn't match the source document's intent.

The fix is a one-liner — reverse the chain before merging so base is processed first and derived writes last:

chain.reverse().forEach((rPr) => { … });

This only affects documents where a character style is derived from another character style and both define the same run property with different values — a real, if uncommon, pattern in Word templates. Single-level style references are unaffected.

---

Everything else looks correct from a spec standpoint: w:tcW omission is valid per §17.4.71 (defaults to auto), the tblPr mutation fix is safe, and runPropertiesInlineKeys/tableCellPropertiesInlineKeys as internal-only attrs (not written to XML) don't create any conformance issues.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eaa6b03cab

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[caio-pizzol]

@VladaHarbour clean approach — tracking inline keys to avoid exporting inherited styles makes sense.

two things to fix: the style chain merge is in the wrong order (base overwrites derived), and the cell property filter drops user edits that weren't in the original import. also worth checking whether existing collab docs could have null inline keys — if so, export would strip their formatting.

minor cleanup: runPropertiesStyleKeys is saved but never read on export. run-properties-export.js has no unit tests. left inline comments.

[caio-pizzol]

the merge loop processes derived styles first, then base styles — so base wins. it should be the other way around. add chain.reverse() before the loop.

[VladaHarbour]

added

[caio-pizzol]

this drops any cell property that wasn't in the original docx. but if a user adds a background color or changes alignment after import, those keys aren't in the allow-list and get silently removed on export. the border command handles this correctly (table.js:1253) — other editing commands need the same treatment.

[VladaHarbour]

The issue was related to tcMar only to be honest and we already treat it above. Removed this check

[caio-pizzol]

when run properties haven't changed, this returns early without setting runPropertiesInlineKeys. if any existing collab docs were saved before this PR, they'd have null inline keys — and export would drop all their formatting. is that a real scenario?

[VladaHarbour]

added condition to support existing collab docs

[caio-pizzol]

runPropertiesStyleKeys is saved during import but never used during export — export recomputes it from scratch. either use the saved value or remove it.

[VladaHarbour]

fixed

[caio-pizzol]

this wrapper just adds an Object.keys() call on top of resolveRunProperties. only one place uses it. worth inlining at the call site instead?

[VladaHarbour]

made it inline