dump: in-cell images are serialized as literal "[image]" text — support base64 round-trip

[ts8050000]

Background

The dump command's replayable batch script is a great fit for a template-as-code workflow: keep the template as a plain-text script under version control, then rebuild the workbook with create + batch. We tested this end-to-end on v1.0.139 (win-x64) with a real report template (styled headers, merged title, number formats, borders, a formula, and one in-cell image), and the fidelity is excellent — after a full dump / → create + batch round-trip, styles.xml is identical and sheet1.xml is byte-for-byte identical except for the image cell.

That image cell is the one remaining gap.

Current behavior (observed on v1.0.139)

Given a workbook where C3 carries an in-cell image (set via --prop image= per #239), dump / serializes the cell as the literal text [image] inside the import data block:

{"command":"import","parent":"/Sheet1","props":{"start-cell":"A1"},
 "text":"Monthly Report\nItem,Value,Photo\nTotal hours,1234.5,[image]\nHeadcount,57\n,=SUM(B3:B4)\n"}

There is no image= instruction anywhere in the dump output, and the alt text is lost as well.

Replaying that script consequently produces a workbook with no image:

• Missing parts: xl/media/*, xl/richData/* (rdrichvalue, rdrichvaluestructure, rdRichValueTypes), xl/metadata1.xml
• The cell degrades from a richValue to a plain string:

<!-- original template -->
<x:c r="C3" t="e" vm="1"><x:v>#VALUE!</x:v></x:c>

<!-- after dump + replay -->
<x:c r="C3" t="str"><x:v>[image]</x:v></x:c>

Repro steps

officecli create template.xlsx
officecli batch template.xlsx build.json      # includes: {"command":"set","path":"/Sheet1/C3","props":{"image":"photo.png","alt":"Site photo"}}
officecli batch template.xlsx dump.json       # [{"command":"dump","path":"/"}] -> dump output
officecli create replayed.xlsx
officecli batch replayed.xlsx <dump-output>   # image is gone; C3 contains the string "[image]"

Proposal

Have dump serialize in-cell images with the actual image bytes embedded as base64, so a single dump script is a complete, self-contained template. The exact shape is of course your call — e.g.:

• "image": "base64:iVBORw0KGgo...", or
• a data URI (data:image/png;base64,...), or
• a separate field alongside the emitted set command.

The alt text should be preserved in the same instruction. If floating pictures (add --type picture) have a similar serialization gap, it may be worth covering them in the same design — we have not tested that side, so no claim there.

Relation to #239

Same template-as-code workflow: #239 solved the write side (setting in-cell images from a batch script, which we verified works great in v1.0.139). This request is about the serialization side — making dump emit what set --prop image= can now consume — which would close the loop and make dump scripts fully round-trip-safe for image-bearing templates.

[goworm]

Thanks for the detailed repro and the well-scoped proposal — this is fixed on main.

dump now serializes an in-cell image as a self-contained set instruction, with the image bytes inline as a data URI and the alt text preserved:

{"command":"set","path":"/Sheet1/C3","props":{"image":"data:image/png;base64,iVBORw0KGgo…","alt":"Site photo"}}

Replaying that script through create + batch rebuilds the richValue image byte-for-byte (identical media SHA-256) instead of the old [image] placeholder string.

On the floating-picture side you asked about: add --type picture already round-trips through dump the same way — bytes emitted inline as src="data:image/png;base64,…" — so image-bearing templates are now fully self-contained in a single dump script.

Landed in #248.