Accept SVG as an image, and keep it vector

[marcosqlbi]

SVG now works everywhere an image works: clipboard paste, Explorer drag-and-drop, File → Import, and .wimport recipes. It is stored as its markup and redrawn at whatever size it is shown at, rather than rasterized once on arrival.

Why a dependency

WPF has no SVG decoder, so supporting SVG at all meant taking a rendering library — including the option of rasterizing on arrival, which needs one just the same. That made the choice about which library, not whether to have one.

SharpVectors.Wpf produces a DrawingGroup, which is the point on a canvas whose zoom is unbounded. It is BSD-3, managed-only, and ships no native binary, so it stays out of the signing step and out of the per-architecture question the installer would otherwise have to answer. Direct2D was the tempting alternative — Vortice is already referenced and it would have cost nothing — but it implements a restricted SVG subset with no <text> element, which is most of what a DAX SVG measure emits. Decision 21 records this.

What carried and what needed work

Adding .svg to ImportCatalog is what carries it into drag-and-drop and .wimport, since both already route through it. Paste needed the work. SVG arrives either under one of five clipboard format names or, more often here, as markup that was simply copied as text, so the shape of the content decides. The root element has to be svg — matching on "contains <svg" would make a page of HTML with a picture inside it paste as an image. Copying an SVG container publishes the markup and a bitmap together, so an editor receives the source and a slide receives the picture.

BoardImageCodec becomes the one place an asset's bytes turn into something drawable, and BoardSurface caches ImageSource rather than BitmapSource.

Two details worth stating

The renderer is given ExternalResourcesAccessModes.Ignore. Its default fetches whatever the markup names, which would let a pasted or dropped file turn opening a board into an outbound request.

A vector is grown to a legible edge on arrival, because icons are authored at 16 or 24 units and would otherwise land as a speck on a 2400-wide row. Enlarging costs a bitmap its sharpness and a vector nothing.

Compatibility

Assets were already stored as opaque bytes carrying a content type, so the board format did not move — it is still version 5. The decoder is chosen from the bytes rather than the stored content type, so boards written before this change are unaffected. A board holding an SVG opened in 1.0.3 draws the missing-image placeholder for it rather than failing to open.

.svg is deliberately not registered as a file type by the installer. Whiteboard opens SVG; it does not take it from the browser.

Verification

Beyond the smoke tests, the real code paths were exercised against a throwaway harness:

• Shapes, <text>, gradients, namespace prefixes, viewBox-only, and a doctype prologue all render.
• The author's declared canvas is preserved. EnsureViewboxSize was needed for this: without it a label centred in a 300×60 canvas arrived cropped to its glyphs at 147×26 and stretched.
• An <image href="http://…"> is ignored, with no fetch.
• A board with an SVG asset round-trips through .wboard byte-for-byte and renders identically at 1024×512 — vector, not a 200×100 bitmap enlarged.
• docs/samples/contoso-workshop.wimport, which now includes an SVG container, resolves with zero missing files.

🤖 Generated with Claude Code