fix(super-converter): fix table-cell shading export — strip # prefix and emit val="clear" (SD-3142)#3312
Open
nazlo90 wants to merge 1 commit into
Conversation
…and emit val="clear" (SD-3142) OOXML requires w:fill to be a bare 6-char hex string and w:val="clear" for solid fills. The exporter was emitting the color as-is (including a leading #), and omitting w:val entirely — both invalid per ECMA-376 §17.4.32. LibreOffice interprets a missing val as "nil" and renders the cell black regardless of the fill value. Two changes in the export path: - `translate-table-cell.js`: strips the # prefix via normalizeHexColor before writing w:fill, adds val:"clear" to the shading object, and guards against non-hex values (e.g. "auto") so they don't produce invalid markup. - `helpers.js` (resolveShadingFillColor): adds an isValidHexColor guard so that w:fill="auto" — a sentinel that Word uses to mean "no fill" — returns null instead of the string "AUTO", preventing it from being surfaced as a color downstream. 11 new tests across helpers.test.js and translate-table-cell.test.js; corrected an existing wrong assertion (w:fill was expected as '#FF00FF'; OOXML requires 'FF00FF'). All 12827 existing tests continue to pass. Not fixed in this PR: the import side of SD-3142 — cells with a table-style-inherited background currently render as white in SuperDoc's layout engine because the style cascade resolution (style-engine) doesn't yet propagate the conditional-format shading fill through to the painted cell. That path requires changes in style-engine and pm-adapter and is left for a follow-up.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partial fix for SD-3142. Addresses the export half of the bug — the import half is not fixed in this PR (details below).
Root cause
ECMA-376 §17.4.32 requires
w:fillto be a bare 6-char uppercase hex string and, for solid fills,w:val="clear". SuperDoc was writing the color from the internal ProseMirror attr as-is, which could include a leading#(e.g.#A1B2C3), and was omittingw:valentirely. LibreOffice treats a missingw:valasnil(transparent) and ignores the fill value, rendering those cells black regardless of color.What changed
translate-table-cell.js— the export path for<w:shd>:normalizeHexColorto strip the#prefix and uppercase the value before writingw:fill.val: 'clear'to every solid-fill shading element."auto") viaisValidHexColor: these now produce no<w:shd>rather than invalid markup.helpers.js(resolveShadingFillColor) — used on the import/display path:isValidHexColorguard sow:fill="auto"(Word's sentinel for "no fill") returnsnullinstead of the string"AUTO", preventing it from being treated as a color downstream.Tests
11 new assertions in
helpers.test.jsandtranslate-table-cell.test.js. Also corrected an existing wrong assertion that expectedw:fillas'#FF00FF'; OOXML requires'FF00FF'. All 12 827 existing tests pass.What is NOT fixed
The import side of SD-3142: cells whose background comes from a table style's conditional formatting (e.g.
tblStylePrwithtype="firstRow") currently render as white in SuperDoc's layout engine. The style cascade instyle-engineresolves the conditional-format shading, but that value isn't threaded through to the painted cell yet — it requires changes instyle-engineandpm-adapterand is a separate, larger task.Related: SD-3142.