Support .d2.svg and .d2.png like .drawio.svg / .drawio.png in VS Code extension

[terrastruct]

Support .d2.svg and .d2.png like .drawio.svg / .drawio.png in VS Code extension

[BarryNolte]

It took me a minute to wrap my head around this, but it's pretty simple in concept. I'll assume that it's implemented with metadata in the svg and png files. So an SVG or PNG file has D2 file contents stored as metadata. If the extension opens one of these SVG/PNG files, it extracts the metadata as editable text, then when it renders (using D2 on the command line), it puts the text into the SVG/PNG file, which if opened by a image viewer, shows as a fully formed SVG/PNG image.

This solves one BIG problem, it allows you to have a single file for markdown embedding. So when you embed 'foo.d2.svg', it just works for markdown (e.g. github). No editing your source file, then forgetting to run the conversion to another file that is actually embedded into your markdown.

Not my decision to make, and would require some work on D2 cli, as well as the extension. I rate it as 'highly interesting'

[alixander]

we don't want editor lock-in, where your teammate uses vscode and you use vim and you can't decode unless you download vscode. i think this is a good feature to do, but we'd have it in the CLI to do the embedding, so that VSCode users can call the command automatically, and others can do it manually. we also want to make sure the encoding/decoding is the exact same code for all editors (e.g. where in the SVG it looks for the script), so it needs to be centralized in the main program.

shouldn't be hard to do and I think a good idea. i'm wondering if we should include the D2 script in the encoded form to save space (like a playground link https://play.d2lang.com/?script=qlDQtVOo5AIEAAD__w%3D%3D&), or include the raw script for preservation and readability without an outside tool. leaning towards the former, but let me know if you have any thoughts.

thanks @shah !

[BarryNolte]

After walking the dog and thinking about this, I agree that as much functionality should be pushed to the CLI. Then everyone can benefit, not just vscode users. On encoding the data, I would suggest against, having it as clear text is easier to code, easier to test, easier to debug and given the average size of a D2 file, no major space saving and disk space is cheap.

[shah]

Thanks for the quick look @BarryNolte -- glad to see you find it interesting.

In my opinion, this "D2 as meta data" embedded in SVG or PNG files could be strictly a feature of the VS Code extension (like hediet.vscode-drawio) and should not require any changes to the D2 CLI.

That's because an .d2.svg or .d2.png file would be only "editable" by those who understand the metadata. A regular .d2 file (processed by the CLI) would remain unchanged.

[alixander]

the concern with space pertains more to serving images over the web.

i'm not sure what the exact flow for easier to test/debug is, can you elaborate on a use case?

[BarryNolte]

Still probably doesn't make a difference. I have a 6.3Kb test file that's pretty average++, but it creates a 1.6Mb svg and 1.8Mb png file. So, even with 100% compression, it's a 0.4% savings.

I'm just thinking of myself, but if I'm inserting stuff into a file, I want to be able to see it as plainly as possible. The D2 file doesn't hold any secret that isn't present in the svg or png file, so it's not a security problem. It's just an extra step that doesn't really provide a benefit.