Using as libary

[marcrleonard]

Hello! I maintain a generate art library for python called LineDream. I've implemented a simpler 'viewer' that rasters the output SVG into a PNG via Cairo, and opens it via Pillow. I'm wondering if this package is a better option. Can vsvg be used as a library and take in an SVG string in memory for viewing?

[abey79]

Hey, thanks for reaching out!

LineDream looks really nice! It has some similarities with my other project vsketch, which is also inspired from Processing but sticks to the stateful API. My first thought, if you haven't done so, would be to ensure that the pen-plotter community is aware of your project. I recommend joining the DrawingBots's Discord server. Also, #plottertwitter on the bird site, and #penplotter on the elephant site.

vsvg currently is a weird of multiple things:

• my first, big-ish "learn Rust" project
• a prototype of what could be the core data library for my more mature vpype project
• ...which indeed includes a SVG importer, which is a forked version of usvg
• a extremely-poor-man pipeline-style CLI in the style of vpype, for testing purposes
• a wgpu-based rendered for vector data

As such, it can be used to display a SVG via command line: vsvg path/to/my.svg. The vsvg-viewer crate could certainly be used on its own to build a Python native module that could display a SVG passed as string. However, like all my projects, vsvg is currently targeted a plotter-centric use-cases and currently draws only strokes. No fill, much less advanced SVG features (gradient, etc.), no text, etc. This might be a bit much of a limitation for a general-purpose gen art library.

As a side-note, vpype includes my first iteration of a viewer implemented in Python, based on OpenGL (via ModernGL) and wrapped in a PySide UI. You can give it a try with: vpype read path/to/my.svg show. The existing vpype/vpype-viewer API would also make it relatively easy to use as library from Python code that produces SVG, albeit with the same limitations as above, plus that fact that it only supports layer-level color/stroke width, not path-level as is the case for vsvg.

What are your thoughts on the above? Can you tell me more on your needs? vsvg being a Rust project, I also wondered if you have a specific interest in going in that direction?

[marcrleonard]

Hi! Ok, so you raise quite a few points worth addressing. Let me layout what my end goals are

• Minimize friction using LineDream - especially the iterative processing of coding, viewing output, coding, viewing output, etc...
• I want a FAST render process (granted, I may need to adjust the internals of LineDream, but not writing the file to disk speeds things up)
• In the future, if I can get it fast enough, I'd like to support a full render loop to create animations (like processing/p5)
• (cont.) Makes me wonder if I should implement more of the core in Rust (like polars, for example). Then I can keep the language syntax in python but all the math/rendering in Rust. Currently, I'm using numpy, but... eh... Doing it in polars seems more fun :-)

With all that said, I love how you created vsketch as an entire environment. So, maybe my original question should be - is it possible to plumb LineDream into vsketch as an alternative 'language'? It seems like you have most of the things in there I would like :-)

However, the only big missing feature, from my perspective, is not supporting fills and stroke color for paths. I totally understand why that may feel outside of the scope of plotters, but you can use plotters to do fills if you get creative. Additionally, it allows you to visualize mixed media (for instance, a piece of art that has a plotter outline with watercolor infill).

Thanks for responding! I'm excited to here what you think.

[abey79]

is it possible to plumb LineDream into vsketch as an alternative 'language'?

Yes probably. As a matter of fact, you could readily use LineDream within a vsketch sketch, and export SVG + vsk.vpype(f"read {path}") to see the result and that would work. Surely the plumbing could be improved to make this smoother.

However, the only big missing feature, from my perspective, is not supporting fills and stroke color for paths.

Fair enough. vsketch (or more precisely, it's vsketch.Vsketch drawing API) does support fills, but actually generate the hatching pattern required for plotter output. I totally understand that this doesn't cut it for your use case.

That being said, it's a bit hard to make concrete suggestions, as much would depend on your aspirations (going native with Rust?) and the available time to invest.

The first thing I'd try to make clear is the debate vs. viewer features (in terms of how much of the SVG spec is supported) vs. performance/scale independance. It would be rather easy to cobble together a native SVG viewer package for python using a PyO3 + egui + resvg stack. resvg being a CPU-based (I believe) rasteriser, this will put a limit on performance and scale independence. On the other hand, if you can live with a minimal feature set (basically uniform stroke and fills, maybe a bit more if you fancy playing with shaders), it's relatively easy to go the GPU accelerated way, which gives you perf and scale independence (zoom in/out, pan, etc.).

If you think of going for the later approach, then both of vpype-viewer and vsvg-viewer pave the way in the right direction. They both would need support for fills though, which basically means implementing tessellation of non-convex polygon (+ some details for clean stroke/fill if you support transparency) and push some more triangle to the GPU. Since the data model of vsvg is already more flexible (path level properties) and more performant, that would technically be the more sound way to go.

As it turn out, I actually would very much like to build a Rust-native Python package to power a "vsketch2" IDE. It would be made of data structures (doc -> layers -> paths), operations on them (crop, SVG import/export, optimisation, etc.), the viewer itself, and a property-based "auto-UI" like vsketch (user parameters shows up as widget on the GUI). The stack would be as the current vsvg: egui + wgpu. It would then be easy to slap any drawing API on top of that (that API would basically fill the data structure with what needs to be displayed). Unfortunately, I don't have enough time for this at the moment.

[marcrleonard]

Thanks Antoine, this is super helpful. I think I need to do a bit of soul searching for the project to determine where my energy is best spent. Thank you for the information!

[marcrleonard]

Also, I think you're right that vpype-viewer might best pave the way. I feel as though that encompasses the majority of the functionality I'm looking for (minus no fills). When I get some spare time I'll have to see what type of data models it expects and how difficult it would be to make mine match yours.

[abey79]

Let me know how it goes, happy to assist if needed!