-
Notifications
You must be signed in to change notification settings - Fork 9
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
Adding additional code->svg tools #133
Comments
I support If we head in this direction, would we be open to adding other renderers to the family or prefer to keep it small? I'm thinking of things like d3. There's definitely maintenance burden associated with all three approaches but I think crates are a great isolation unit for encouraging seperation of concerns. Happy to be a part of it :) |
Oh, looked at the rust to go build setting. Not nearly as complex as I was reading from the initial description, seems perfectly acceptable. |
Better bindings would be great but I didn't find any (I didn't search that hard), right now I've just been serializing to json to simplify it / only implementing exactly what I need. Another option would be something like https://github.com/mozilla/uniffi-rs but that might be more annoying than json. Right now my
This will definitely cause issues for consumers without golang installed. https://github.com/ryanfowler/cgo-rs/blob/main/src/lib.rs#L184 seems like it would do more but also still have issues for people without golang. |
I'd be open to adding more renderers but as showcased by my slow upkeep of the graphviz renderer I can't promise any support for them. But that's part of the beauty of open source right? 😄 I'll work on combining what I have in my local repo to the latest master and get a PR up for some review |
I've been working on an mdbook d2 renderer lately and most of the code is exactly the same as the graphviz code. It would be great to share some of the logic / backport the improvements I've made (svg zoom and pan) back to this repo.
I think there are a few ways we could do this:
mdbook-preprocessors
, have a shared cratemdbook-inline-svg-preprocessor
, then have each preprocessor inherit frommdbook-inline-svg-preprocessor
.Right now I'm inclined to go with Option 1. Option 2 seems too tedious to be reasonable. Option 3 seems compelling but I've been calling d2 via their golang library instead of the CLI which (while very powerful) introduces some interesting compilation requirements in osx. I wouldn't want to break graphviz rendering for any consumers outside of osx, especially if it proves challenging to setup the correct install for consumers without golang installs.
The text was updated successfully, but these errors were encountered: