Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
shah opened this issue Jan 19, 2023 · 6 comments

Comments

@shah
Copy link

shah commented Jan 19, 2023

D2 is a fantastic project, especially the VS Code extension which makes it easier to edit files. I'd like to suggest that the VS Code extension team add the type of slick SVG and PNG integration offered by hediet.vscode-drawio extension.

As stated in the hediet.vscode-drawio documentation:

  • .drawio.svg are valid .svg files that can be embedded in Github readme files! No export needed.
  • .drawio.png are valid .png files! No export needed.

It would be cool to have the same functionality for D2 diagrams:

  • .d2.svg would be valid .svg files that can embed their D2 into the SVG and then the SVG can be easily used directly in Markdown and other files
  • same with .d2.png

Once D2 code can be embedded into an .d2.svg or .d2.png file, the visual and code can be managed in the same file and be easily editable by VS Code at the same time.

Thanks!

@BarryNolte
Copy link
Collaborator

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'

@shah
Copy link
Author

shah commented Jan 19, 2023

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
Copy link
Contributor

alixander commented Jan 19, 2023

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
Copy link
Collaborator

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.

@alixander
Copy link
Contributor

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
Copy link
Collaborator

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.

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

No branches or pull requests

3 participants