Skip to content

Export the diagram as SVG the way the mlir-viewer does - #78

Merged
endrix merged 1 commit into
mainfrom
feat/svg-export-as-mlir-viewer
Oct 16, 2026
Merged

endrix merged 1 commit into
mainfrom
feat/svg-export-as-mlir-viewer

Conversation

@endrix

@endrix endrix commented Oct 16, 2026

Copy link
Copy Markdown
Owner

The exportSvg command dispatched GLSP's stock RequestExportSvgAction, which hands out the rendered SVG without its styles: every fill and stroke stayed behind in the webview's stylesheet, and the file opened as black boxes in anything but a browser with the stylesheet.

This ports the mlir-viewer's extraction (packages/client/src/svg-export.ts there) into the shared client, for every profile:

  • Client (svg-export.ts, svg-export-command.ts): the rendered root group is cloned; the computed value of every property that decides the look is written onto the clone (the two lists, SVG and HTML in foreignObject); url(vscode-webview://…#arrow) becomes url(#arrow); color(srgb …) becomes rgb() for Inkscape and librsvg; hidden elements are dropped; the root's defs and the background travel along; the whole is lifted into a viewBox of its own, at 1:1 whatever the viewport's zoom. The webview answers the extension's dialogram.svg.extract with dialogram.svg.extracted, carrying the file, a name from the workflow shown, and the element count. A palette header button, Export diagram as SVG, does the same.
  • Extension core: the command posts the request to the active diagram's webview; the editor provider saves what comes back through VS Code's own dialog, defaulting beside the source file as <workflow>.svg, and offers Open or Reveal in Explorer, as the mlir-viewer does.
  • Tests: the pure parts (url localisation, colour normalisation, file name), and a coverage test that reads diagram-client.css and fails on any property neither list carries and the excused list does not name, so a new stylesheet property cannot silently go missing from exports.

Two differences from the mlir-viewer, both because this client has no semantic zoom and does not cull off-screen elements: no detail quick pick, and no canvas enlargement. The whole diagram is what the file holds.

252 client tests, 309 extension-core tests, tsc --noEmit and the extension bundle pass. wfpy-ide contributes the command since endrix/wfpy-ide#21; streamblocks-ide's profile declares it but its package.json does not contribute it yet.

The exportSvg command dispatched GLSP's stock export, which hands out the
rendered SVG without its styles: every fill and stroke stayed behind in
the webview's stylesheet, and an opened file showed black boxes. The
mlir-viewer's extraction (its packages/client/src/svg-export.ts) is
ported into the shared client: the rendered root group is cloned, the
computed value of every property that decides the look is written onto
the clone, url(#...) references are made local again, CSS Color 4
colours become rgb() for Inkscape and librsvg, hidden elements are
dropped, the defs and the background travel along, and the whole is
lifted into a viewBox of its own, at 1:1 whatever the zoom. The webview
answers the extension's request with the file and its name, the editor
provider saves it through VS Code's dialog beside the source, named
after the workflow, and offers to open or reveal it. A palette header
button does the same. The coverage test holds that every property the
stylesheet declares is carried or excused by name.
@endrix
endrix merged commit 19f7460 into main Oct 16, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant