Hacker News Reader

Comment by zxcvgm | Hacker News Reader

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.

View on HN

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"/>

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

These are the comment threads I love HN for.

+1 yes! this got deep very quickly

You can make this even 4 chars shorter by using relative move-to commands (small 'm'):

    M21 5H3v1h18m0 5H3v1h18m0 5H3v1h18

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!

A couple fewer bits or bytes is not going to make a noticeable performance difference.

So? Golfing things like this is mostly about fun, with a side benefit of being aware of things that, on a (much) larger scale, do start to matter.

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

There's SVGO (https://github.com/svg/svgo).

I knew there was something I forgot about; SVGO was probably it. Thanks!

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!

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

Reply on news.ycombinator.com