scour
scour copied to clipboard
Suggestion: Merge paths with the same attributes
Some applications export geometry one line segment at a time, each of which gets its own element. Those can sometimes be merged into a single path if they all have the same attributes, especially if they have no fill.
@ygra I agree this feature would be nice for example for https://commons.wikimedia.org/wiki/File:1_42_polytope_7-cube.svg which contains 483,840 (straight) lines.
However svgo has this feature, and has problems with marker-end
see https://github.com/svg/svgo/issues/872 or https://github.com/svg/svgo/issues/958
before | after |
---|---|
![]() |
![]() |
I see, you've tried already on that large image ;-) The saving seem significant but apparently neither rsvg, nor Firefox are able to render it. That's probably not worth it, then. Otherwise the size-optimal way of rendering that image would probably be to have a few giant path
s. One path
for the lines, another for the circle outlines rendered with zero-length segments and then one for each colored circle, also with zero-length segments where a circle is needed. Might still be a neat trick for smaller diagrams :-)
My context at that point was chemical structure diagrams like https://commons.wikimedia.org/wiki/File:Araloside_A-.svg where BkChem outputs every bond as a single line and also switches between round and butt linecap, depending on whether there's an atom at the end. So I go in after export in Inkscape, merge many of the paths, ensure that corners are pointy again and try cleaning up the result as much as possible.
I've already looked at the scour source code and things like marker attributes are already considered in some points to avoid butchering the result, so this could probably still be done with a flag.
I'd love to see this, but are "geometric" optimisations out of scope? I had the impression scour
is just about removing cruft.
I'd been thinking about starting a new project focused on this sort of thing. svgo
and svgcleaner
fulfil some of my requirements, but are barely maintained and, by their respective creators' admission, poorly engineered.
Another case where this breaks is svg/svgo#1267, still not fixed. Two paths filled by the same <linearGradient>
with the default gradientUnits="objectBoundingBox"
cannot safely be merged.
I'd been thinking about starting a new project focused on this sort of thing.
FWIW, I did: https://github.com/georgefst/svgone
It's good enough at merging paths for the use case I had at the time. But it's totally undocumented and I haven't had any motivating use case to go back to it since January.