Export PNG from the browser instead of the server

[ctgnz]

Idea

#37 removes server-side PNG rendering, and with it the JavaFX toolkit, xvfb and GTK. The scope argument for that is sound — JMSFX is an SVG tool — but it does take away a convenience: someone wanting an icon for a slide or a wiki wants a PNG, and "go and install Inkscape" is friction at exactly the moment they were about to succeed.

A browser can rasterise SVG perfectly well on its own. The Generate page could keep an Export PNG button that does the conversion client-side, with no server involvement at all.

Sketch

Draw the SVG the page already has into a <canvas> and export it:

1. fetch the composite SVG (the same URL Export SVG uses)
2. load it into an Image via a blob or data URL
3. draw it to a canvas sized to the requested pixel width
4. canvas.toBlob() and offer it as a download

The size selector removed in #37 would come back, driving the canvas dimensions rather than a query parameter.

Why this should work here

The usual pitfalls of canvas SVG rasterisation are external references and web fonts, which taint the canvas or fail to load. JMSFX composites are self-contained paths assembled from the symbol fragments, so neither applies.

Worth confirming when implementing:

• that the rendered output matches what the server used to produce, particularly around the viewBox and cropping — note that since Compose SVG output without requiring the JavaFX toolkit #32 the composite carries the full APP-6E canvas, so the client would need to decide whether to crop to visible content the way the old server-side path did
• transparent background is preserved
• behaviour on Safari, which has historically been the fussiest about SVG-in-canvas

Payoff

The feature survives for users, and the server keeps none of the cost — no toolkit, no native libraries, no virtual display, and no request that can hang.