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.
Background
The
dumpcommand'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 withcreate+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 fulldump /→create+batchround-trip,styles.xmlis identical andsheet1.xmlis 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
C3carries an in-cell image (set via--prop image=per #239),dump /serializes the cell as the literal text[image]inside theimportdata 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:
xl/media/*,xl/richData/*(rdrichvalue, rdrichvaluestructure, rdRichValueTypes),xl/metadata1.xmlRepro steps
Proposal
Have
dumpserialize 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...", ordata:image/png;base64,...), orsetcommand.The
alttext 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
dumpemit whatset --prop image=can now consume — which would close the loop and make dump scripts fully round-trip-safe for image-bearing templates.