Ignoring fill() information limits the library

[mariuswatz]

I love the return to Processing beginRecord logic, but don't understand the decision to ignore fill() commands. I understand the focus on output for plotters, but ignoring fill misses out on usefulness as a SVG generator.

I'm assuming that exporting fill info is technically the same as exporting information about stroke, obviously. A possible fix for newbies thinking fill will automatically work for plotters might be to print a warning to console if you use fill() while exporting.

[golanlevin]

sigh
♡ Hi pal ... thanks for your suggestion.

I hope/assume you've read the arguments in my statement on What the p5.plotSvg library IS NOT.

Indeed, my basic goal here has been to make a small, single-purpose library, focused on the specific needs of plotterheads, which is easy to add to regular p5 projects.

p5.plotSvg adheres to the core idea that geometric paths are logically separate from the visual tools (pens, paintbrushes, cutters) which enact and trace them out in the world. Omitting fill() isn't just about ensuring that newbies are aware of the limitations of plotters; it's also about avoiding a slippery slope of supporting the full SVG specification ...including visual phenomena like gradient fills, alpha transparency, pixel-based images, blur filters, strokeWeight, etc. etc. etc.

I respect where you're coming from, of course, and I completely understand your point. Are you aware of Zenozeng's p5.js-svg library? p5.js-svg is an actual SVG renderer in the browser (swapping the p5 Canvas renderer for the SVG Document Object Model), and supports the full SVG specification. There is even chatter about integrating it into the p5 core. In my opinion, the only major downside of Zenozeng's p5.js-svg is that (as of 2025) it runs rather slowly in the browser for real-time graphics with e.g. thousands of particles.

I will give some more thought to adding in fill(), but my hunch is that it may quickly lead to a "give a mouse a cookie" scenario in which it can never compete with the on-screen visuals achievable with p5.js-svg.

[mariuswatz]

I can hear you groaning from here, old friend! :)

Not surprised to hear your reasoning, which does make total sense. I was aware of the p5.js-svg library, if it gets integrated into p5js core that would be obvious go-to solution for SVG. But I do appreciate the beginRecord() convention of olden days, which allows you to run a sketch in a regular context and export on demand.

Which leads me to why I still wish your library would support fill() (and probably strokeWeight, come to think of it.) The use case is the ability to export graphics in two versions, plotter-ready and regular color, without switching libraries.

I'll probably end up writing a hack to add fill support to plotSVG "in situ", will post it as a Gist if I do.

As to the more plotter-explicit side of things, I love the idea of a plotter-first SVG library. There's a lot of code tools for prepping graphics for plotting that would be so nice to have. Hatching, clipping to a rectangle, auto-centering / auto-scaling of graphics etc.

I realize all of that is beyond your library for now, since you don't store a representation of the graphics. I'm just dreaming here...

[golanlevin]

I'll think about this some more. To the greatest extent possible in this library, I have tried to abstract out the geometry of paths from how they are visually styled, with the expectation that the way a path eventually appears is a function of what sort of physical crayon you happen to have stuffed into the plotter.

Of course, I can imagine some situations in which it could be useful to abuse p5.plotSVG for simple visually-oriented SVG outputs. But the "and probably strokeWeight, come to think of it" is the kind of slippery slope I'm afraid of.

for prepping graphics for plotting that would be so nice to have. Hatching, clipping to a rectangle, auto-centering / auto-scaling of graphics etc.

For many such purposes (with the exception of hatching) I strongly advise using Antoine Beyeler's vpype, a command-line tool which can also perform very sophisticated path optimizations and plotter prep; it would be pointless to duplicate this powerful tool. Note that vpype is Python based and (in my opinion) should always be used from within a virtual environment.

[golanlevin]

@mariuswatz Hi — I'm re-opening this issue, as I've found a roundabout way to support this, and I am now most of the way towards implementing a solution.

Long story short: for completely unrelated reasons, I'm making it possible to inject arbitrary attributes into the SVG code generated by p5.plotSvg. (I'm doing this in order to make p5.plotSvg more "extensible" — in particular, I'm implementing an addon library that allows plotSvg to support the Inkscape PowerStroke path effect for editable, variable-width calligraphic lines. My plan is to (ab)use the variable strokeweight in order to continuously control the pressure (z-axis height) on appropriately-equipped pen plotters.)

Along the way, it turns out that this effort allows a p5.js end-user to easily inject visual styling attributes, such as style="fill:#000000; stroke:none; stroke-width:0; fill-opacity:0.25" into desired SVG elements. However, please note that this styling information will not be injected by invoking the standard p5 operators (fill(), strokeWeight(), etc.); instead, it will require using a special injection command. So it's a compromise solution — a bit of a workaround for power-users or for special situations. p5.plotSvg remains a library primarily intended for pen-plotting, and for exporting style-agnostic geometric paths.

Stay tuned!