fix(pptx): resolve theme colours in persisted custGeom (brand-coloured vectors round-trip cross-process)#71
Merged
Conversation
…red vectors round-trip cross-process
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
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.
Follow-up to #69. Closes the gap that left the eon bicycle blank even in 1.16.1, which already shipped cross-process verbatim persistence.
Why the bicycle still blanked in 1.16.1
#69 only stamps a custGeom shape's verbatim
<p:sp>into the deck JSON when the XML is fully self-contained, and it excluded any<a:schemeClr>(theme colour) reference. Brand marks are almost always filled with a theme accent — E.ON red isschemeClr val="accent2"— so the bicycle was gated out, fell back to the lossy synth path, and still rendered blank. The deck JSON showsfill: "#EA1B0A"because the importer resolves the colour for thefillfield, but the verbatim XML kept the originalschemeClr, which is what the gate rejected.Fix
Instead of bailing on
schemeClr, the importer now resolves it to a literal<a:srgbClr>against the slide's theme before persisting:<a:schemeClr val="accent2"/>→<a:srgbClr val="EA1B0A"/>schemeClrandsrgbClraccept the same child transforms (lumMod,lumOff,alpha, …), so the swap is lossless — tints/shades survive, only the colour source changes from theme-ref to baked hex.Shapes that still reference media (
r:embed/r:id/r:link) or a colour token absent from the theme (e.g.phClr) remain on the synth path — the resolver leaves those untouched and the existing "still has schemeClr → bail" check catches them.Tests (+1, 62 pass)
Unit test on the resolver: self-closing / with-child-transform / closing-tag forms all convert; child
lumModsurvives; unresolvablephClris left intact; noschemeClrrefs remain for resolved tokens. The existingpristineOoxmlstamp + verbatim-replay + edited-fallback tests still pass.tsc -bclean,build:libsucceeds. Off currentmain(post-1.16.1).Net effect
With #66 (synth path-space + drop
fill="darken"), #69 (verbatim persistence), and this, an unedited brand-coloured custGeom vector round-trips byte-faithfully cross-process. If the bicycle still blanks after a release with this, it would have to be media-referencing or genuinely renderer-side — sendeon-deck.pptxand I'll confirm against the built package.