[karthikmudunuri]

Follow-up to the eon-deck fidelity report. I round-tripped each of the three reported serializeDeck bugs through real reproductions — here's what each turned out to be, and the one with genuine emission bugs.

#2 custGeom blank — fixed here (two real emission bugs)

Reproduced the multi-subpath / even-odd / EMU-scale case and inspected the emitted OOXML:

1. fill="darken" was wrong. <a:path fill="…"> is a shading hint (none/norm/lighten/darken) — custGeom has no even-odd winding flag. The code emitted fill="darken" for fillRule: "evenodd", which silently darkened the shape and trips LibreOffice, without ever cutting the hole. Removed — default norm shading; holes come from subpath direction in d.
2. Path coordinate space ≠ shape box. <a:path w/h> was left at the source viewBox while points stayed in that space. PowerPoint emits custGeom with w/h = the shape's EMU extent, and LibreOffice only maps the path onto the box correctly when they line up. svgPathToOoxml now rescales points into the shape's EMU extent.

Honest caveat on the bicycle specifically: for the eon bicycle, pxToEmu(boxW) ≈ viewW already (776px → 4,927,600 ≈ 4,930,510), so the rescale is ~a no-op there — meaning the fill="darken" removal is the likelier culprit for that shape, but I can't 100% confirm without the file. If the bicycle still renders blank after this, please attach eon-deck.pptx (or the bicycle's full path.d + viewW/viewH + shape w/h) and I'll repro the exact path.

#1 radial — not an emission bug (verified)

Reproduced your exact 4-stop radial with no source. serializeDeck does emit it:

<a:gradFill ...><a:gsLst>…</a:gsLst><a:path path="circle"><a:fillToRect l="0" t="100000" r="100000" b="0"/></a:path></a:gradFill>

The grep was for <a:path type="circle"> — the attribute is path="circle", not type=, so it reads 0. Also note this deck's stops are mostly transparent (alpha 0x59≈35%, 0x00, 0x00, 0x59), so it renders faint by design. If a specific radial still doesn't paint, it's most likely LibreOffice's known weak support for <a:path path="circle"> radials rather than emission — happy to add a compatibility shim if you can confirm against PowerPoint.

#3 fonts — works when deck.fonts is populated (verified)

Reproduced with a deck.fonts entry: output has ppt/fonts/* and <p:embeddedFontLst> in presentation.xml. So embedding is wired correctly. The gap is an empty deck.fonts: either the source deck only references the brand font by name (no embedded bytes → the library has nothing to embed), or the large fonts[] array got dropped on JSON upload (you mentioned fixing truncation). To embed, ensure the deck JSON you serialize carries fonts[{ family, data: "data:font/…;base64,…" }].

I skipped the auto weight→named-face rename (300/500/600 → "…Light/Medium/SemiBold"): most font families don't follow that naming, so synthesising "EON Brix Sans Medium" would reference a face that may not exist and make matching worse. That mapping is best owned by the host, which knows its real family names.

Tests

• synth-writers: custGeom path emits <a:path w/h> at the shape's EMU extent and no fill="darken".
• Full suite 58 pass, tsc -b clean.

Note: depends on the gradient/arc/font work from #64 (already merged + released in #65); this branch is off the post-#65 main.