Thanks for posting this! It's an absolute godsend for creating small vector icons.
As an example, I was looking at various popular sites for how they implement the "hamburger menu" icon, and it turns out that YouTube has a really compact one:
When I tried implementing my own in something like Inkscape, it always uses floats for coordinates, no matter how hard I tried to coax it into a fixed grid or using integer values. With that problem alone, you will never be able to get a compact path.
That’s not actually very good or compact path data:
• It has three extraneous points: each rectangle is comprised of five points, because it draws to the start point manually (V6/V11/V17), and then says draw to close the path (z). The V6/V11/V17 should just be dropped: z covers that. In fact, even each z can be dropped, provided no stroke is being used, removing three edges.
• It misses compression opportunities, by having the first one go counterclockwise and the remaining two go clockwise, and by using absolute coordinates in places where the same relative coordinate could be used (e.g. V11/V17 could both have been v-1, and if the first one’s direction was sorted out then that V5 could also be v-1; but we’re eliminating these vees anyway, so—).
Could be replaced with this path data which is more compact, more compressible, and faster to draw by probably at least a femtosecond or two:
M21 5H3v1h18M21 11H3v1h18M21 17H3v1h18
Note in that how `M21 ` and `H3v1h18` are each repeated three times, with `5`, `11` and `17` being the only things that appear once. This attention to maximising exact repetition will save another few bytes.
Depending on how you do things, it could even be better to replace the 12-point fill with a 6-point stroke (though I freely admit that more care is required because of stroke-width, stroke-linecap, stroke-linejoin, mixing fill and stroke, &c.):
FWIW, your optimizations assume well-behaved SVG handling. This one, for instance, will cause problems:
> In fact, even each z can be dropped, provided no stroke is being used, removing three edges.
While that may be true according to the spec, I can tell you from a practical standpoint that it will break in Lightburn. It's SVG handling does unexpected things with implicitly closed paths, which suddenly go away when you explicitly move/stroke back to your starting point or "z".
I have not looked deeper into why, but if I had to make a WAG, I'd suspect it comes from their implementation trying to bridge the gap between SVG generators (which are optimized for "shape looks correct") and machine control instructions (which target the lower level "here are the steps to make this shape look correct"). You're then having to take something simple like a path and adding in the complexities of making machine control instructions for the practical rendering of that path, accounting for things like miters, etc. Seems like a complex layer, prone to tons of annoying little bugs like this.
I presume YouTube's designers/coders aren't worried about being able to run their UI widgets through a laser engraver, but I tend to chalk up these kind of "missed optimizations" to having some similar backstory of "we found this bug in this implementation, so here's the workaround".
I’ve never heard of LightBurn. I presume you’re talking about the laser cutter software? If so, not knowing what it’s actually doing, I presume it’s just cutting along the stroke, rather than trying to do, I dunno, cross-hatch a fill or something? This case is specifically about fill, as I said, so if it’s just a matter of stroke then it’s quite correct in what it’s doing. If it actually is treating it as fill and getting it wrong, then that’s a bug that should be fixed and I have no patience with their implementation because it’s obviously wrong (as in: you’ll come across SVG like this all the time, there’s absolutely nothing anomalous about it).
Hmm, I contemplated that at first but decided against it for some reason that’s not quite clear to me now, but I think I mispredicted its verbosity in both literal and compressed form.
For compression purposes, mine is going to be kinda like this:
> When I tried implementing my own in something like Inkscape, it always uses floats for coordinates, no matter how hard I tried to coax it into a fixed grid or using integer values. With that problem alone, you will never be able to get a compact path.
It's not obvious, but for that you have to save as-> Optimized SVG instead of saving as regular SVG.
One trick I've been using fairly often to ensure integer coordinates is to divide my shape into a uniform grid that can then be stretched to the actual size. Then you can use a combination of the SVG's size, viewBox and preserveAspectRatio='none' to stretch that to the full size. Have used that frequently for flags, e.g. https://commons.wikimedia.org/wiki/File:Flag_of_Biliy_Kamin....
But indeed, when using Inkscape for exact geometric work, you need a lot of care and in many cases editing the file by hand is easier.
Smart quantization of SVG paths sounds like a neat problem. Is there no existing tool for it already? Along the lines of pngcrush or similar.
This may be too-stupid-to-work but what immediately comes to my mind is normalizing all coordinates into an [0,1]x[0,1] interval and then finding an optimal N so that the maximum rounding error for quantizing all coordinates to the nearest K/N (where K is a non-negative integer up to N) is minimal (for some definition of "optimal", since you have two criteria now - resulting path string length AND maximum rounding error achieved for a given N). Then all your coordinate components should be integers in the range of [0,N].
The problem is that the designers of small icons already work with pixel-snapping and for complex graphics, dumb quantization will look and compress no worse. If you want to work on path optimization, improve Inkscape's path simplification, because why bother with the alignment of a control point that isn't necessary in the first place!?
This algorithm should find that very pixel snapping if it exists. Path simplification seems like a more complicated issue, but also promising of course.
Tangent: That's a compact path, though I wonder how much verbiage is added for the svg itself, however it's transmitted. I do wonder why the person who wrote the path added the V before each z, since the z goes to that point, anyway. Also, depending on how they transmit it, it might have been better to do three squared strokes.
I frequently use this to (lightly) edit vector drawables for android: though they are not proper SVG, the path syntax is the same. And, yes, it is a godsend!
I found this while searching for a way to edit paths and it was just the right tool. Every hour I find new features, like
- Snap to grid (on and off - I first thought the drag and drop of dots was not working correctly)
- Minify output
- Import and Download as SVG Button upper right
- Scale and translate
- The three dot menu in the Commands list
With the image import button and opacity settings you can easily manually vectorize raster images.
It's just awesome. I would love to see some more github stars here :-)
I don’t know what you mean by invoking Vim here. Among text editors, there’s nothing particularly special about Vim in its functionality (what you can do with it), it just presents commands in a slightly different way that makes it more efficient when you’re used to it. (I say this as a devoted Vim user for over fifteen years.) This, on the other hand, is focusing on a tiny piece of the functionality of graphics editors, exposing the ability to edit path data as a text/graphic hybrid, a mode not supported in the slightest by any graphics editor that I can think of. It’s functionally radical (it makes novel things possible or feasible), which Vim never was, is or will be.
Is there some other axis you have in mind that I’m not seeing?
I found this some weeks ago and used it to learn how SVG pathes work.
It was enough to write a function making pathes absolute and splitting them into pieces.
As an example, I was looking at various popular sites for how they implement the "hamburger menu" icon, and it turns out that YouTube has a really compact one:
When I tried implementing my own in something like Inkscape, it always uses floats for coordinates, no matter how hard I tried to coax it into a fixed grid or using integer values. With that problem alone, you will never be able to get a compact path.This editor is perfect for doing this.