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
…l + w:val="clear" OOXML requires w:fill to be a bare 6-char hex string and a solid fill needs w:val="clear" (ECMA-376 17.4.32). The exporter wrote background.color as-is, keeping a leading '#' and omitting w:val. LibreOffice treats a missing w:val as nil and renders such cells black regardless of the fill. generateTableCellProperties now normalizes the color to bare hex via normalizeHexColor, guards with isValidHexColor so non-hex values like "auto" produce no w:shd, and emits w:val="clear". Updates the table-cell export tests accordingly.
caio-pizzol
force-pushed
the
nazlo90/SD-3142-fix-table-cell-shading-export
branch
from
9682609 to
d558f53
Compare
Contributor
|
Thanks for this, @nazlo90. I refreshed the branch against current The import-side shading fix is already on |
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
3 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.