5 ms·

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

by zxcvgm 5y ago

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: M21,6H3V5h18V6z M21,11H3v1h18V11z M21,17H3v1h18V17z 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.

ygra 5y ago
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.svg 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.
throwaway744678 5y ago
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!
sandreas 5y ago
You can also use this editor for WPF Controls in C# / XAML!
jhgb 5y ago
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].
- pilaf 5y ago
  There's SVGO (https://github.com/svg/svgo https://github.com/svg/svgo).
  - jhgb 5y ago
    I knew there was something I forgot about; SVGO was probably it. Thanks!
- zuzun 5y ago
  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!?
  - jhgb 5y ago
    This algorithm should find that very pixel snapping if it exists. Path simplification seems like a more complicated issue, but also promising of course.
epilys 5y ago
> 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.
ghusbands 5y ago
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.
chrismorgan 5y ago
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—). All up, that hamburger menu data of this: M21,6H3v-1h18z M21,11H3v1h18V11z M21,17H3v1h18V17z 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.): <path d="M21 5H3v1h18M21 11H3v1h18M21 17H3v1h18" fill="currentColor" stroke="none"/> <path d="M3 5.5h18m-18 6h18m-18 6h18" fill="none" stroke="currentColor" stroke-width="1"/>
- jansan 5y ago
  You can make this even 4 chars shorter by using relative move-to commands (small 'm'): M21 5H3v1h18m0 5H3v1h18m0 5H3v1h18
  - chrismorgan 5y ago
    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: ‹M21 ›5‹H3v1h18›‹M21 ›11‹H3v1h18›‹M21 ›17‹H3v1h18› Yours will probably treat only one block, slightly bigger, as a repeated thing: M21‹ 5H3v1h18›m0‹ 5H3v1h18›m0‹ 5H3v1h18› I expect that would compress 2–5 bytes smaller. I’d lowercase that M, too; it doesn’t need to be uppercase, so it might as well be lowercase like the others!
deleted 5y ago
[deleted]

by zxcvgm 5y ago

ygra 5y ago

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.svg 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.

throwaway744678 5y ago

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!

sandreas 5y ago

You can also use this editor for WPF Controls in C# / XAML!

jhgb 5y ago

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].

pilaf 5y ago
There's SVGO (https://github.com/svg/svgo https://github.com/svg/svgo).
- jhgb 5y ago
  I knew there was something I forgot about; SVGO was probably it. Thanks!
zuzun 5y ago
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!?
- jhgb 5y ago
  This algorithm should find that very pixel snapping if it exists. Path simplification seems like a more complicated issue, but also promising of course.

epilys 5y ago

> 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.

ghusbands 5y ago

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.

chrismorgan 5y ago

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—). All up, that hamburger menu data of this: M21,6H3v-1h18z M21,11H3v1h18V11z M21,17H3v1h18V17z 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.): <path d="M21 5H3v1h18M21 11H3v1h18M21 17H3v1h18" fill="currentColor" stroke="none"/> <path d="M3 5.5h18m-18 6h18m-18 6h18" fill="none" stroke="currentColor" stroke-width="1"/>

jansan 5y ago
You can make this even 4 chars shorter by using relative move-to commands (small 'm'): M21 5H3v1h18m0 5H3v1h18m0 5H3v1h18
- chrismorgan 5y ago
  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: ‹M21 ›5‹H3v1h18›‹M21 ›11‹H3v1h18›‹M21 ›17‹H3v1h18› Yours will probably treat only one block, slightly bigger, as a repeated thing: M21‹ 5H3v1h18›m0‹ 5H3v1h18›m0‹ 5H3v1h18› I expect that would compress 2–5 bytes smaller. I’d lowercase that M, too; it doesn’t need to be uppercase, so it might as well be lowercase like the others!

deleted 5y ago

[deleted]