This looks very good, especially as a teaching tool. Writing and minifying SVG by hand (including path data) is a hobby of mine.
I’m pleased to see that the minification doesn’t put a space after the “0” or “1” of large-arc-flag and sweep-flag; historically I’ve found most minification tools doing so, and even some tools failing to parse `a1 2 3 104 5` (arc: rx=1, ry=2, x-axis-rotation=3, large-arc-flag enabled, sweep-flag disabled, dx=4, dy=5).
One missing optimisation is culling superfluous path commands. If you have two commands of the same type in a row, you don’t need to repeat the letter: `L1 2L-3 4` can become just `L1 2-3 4`; also, after the initial M or m command, it switches to L or l automatically, so in `M1 2L-3 4` the L could be removed.
An area I’d really like to see more work in (in SVG tooling in general) is path simplification/minification. In automated tools I’ve only seen rounding to a fixed number of decimal places, which is what this tool is offering, and which is terrible: some decimal places are far more significant than others, and indeed some points could be happily dropped, and rounding everything is not always the correct behaviour for fidelity. Instead of “two decimal places”, I’d like to see things like “accurate to within one pixel in any given direction”, which I reckon will normally compress better for a given quality level. There’s also the approach taken by Inkscape’s path simplification, which chooses a completely new set of points and curves that approximate the current values, but this harms the accuracy of the path and isn’t flexible enough (you run it in discrete steps, rather than there being a continuous slider or the ability to simplify some sections harder than others, whether automatically for best accuracy or manually).
Awesome project. So nice to see these logos collected in a place with attention to the underlying SVG detail. None of the garbage comments/ids/etc outputted by Adobe and Sketch.
Awesome! One thing I noticed: your LinkedIn logo has an artifact when rendered small in my browser (Firefox). There is a thin vertical blue line between the downstroke and the round stroke in the 'n'.
The GitLab logo has very prominent gray lines between the segments. I recall reading an article about this issue with alpha blending, but can no longer find it.
How do you recommend people send those to the front-end (assuming a web interface)? One request per icon as done in the README is extremely wasteful. Is there a format that allows importing multiple SVG in one request? Embedded at build time? Or as data URL?
Not forgetting compression too as it makes a huge impact on big enough SVG: Firefox goes from 1024 (not 1023?) to 522 bytes, HN goes from 229 to 208.
If it's more then couple svgs that repeat on every page and you want to use them as not just backgrounds (in which case I would recommend special .css file with svgs as data-uris), the best way is in my opinion storing them all in one file and then linking them using their id. It's described for instance in https://www.creativebloq.com/features/the-complete-guide-to-...
There is still a header to send. Talking about SVG that are on average 465 bytes, a 867 bytes header (as sent by GitHub[0]) is not negligible. HTTP compresses headers though, so according to [1] we can expect ~30% header transferred size/actual size ratio which brings header transferred size to ~260 bytes. Still a 56% overhead for the average icon from this collection.
svgo is one of the things that historically didn’t parse arc commands correctly, though if I recall correctly that’s been fixed for a couple of years now. svgo also has the terrible uniform-precision rounding technique. Beyond these things, well, I tend to use SVGOMG somewhere in my process of SVG optimisation. I like it.
Google Maps path simplification aimed to minimize error between original and simplified paths. It’d prioritize dropping points that had the smallest impact on error.
I’m pleased to see that the minification doesn’t put a space after the “0” or “1” of large-arc-flag and sweep-flag; historically I’ve found most minification tools doing so, and even some tools failing to parse `a1 2 3 104 5` (arc: rx=1, ry=2, x-axis-rotation=3, large-arc-flag enabled, sweep-flag disabled, dx=4, dy=5).
One missing optimisation is culling superfluous path commands. If you have two commands of the same type in a row, you don’t need to repeat the letter: `L1 2L-3 4` can become just `L1 2-3 4`; also, after the initial M or m command, it switches to L or l automatically, so in `M1 2L-3 4` the L could be removed.
An area I’d really like to see more work in (in SVG tooling in general) is path simplification/minification. In automated tools I’ve only seen rounding to a fixed number of decimal places, which is what this tool is offering, and which is terrible: some decimal places are far more significant than others, and indeed some points could be happily dropped, and rounding everything is not always the correct behaviour for fidelity. Instead of “two decimal places”, I’d like to see things like “accurate to within one pixel in any given direction”, which I reckon will normally compress better for a given quality level. There’s also the approach taken by Inkscape’s path simplification, which chooses a completely new set of points and curves that approximate the current values, but this harms the accuracy of the path and isn’t flexible enough (you run it in discrete steps, rather than there being a continuous slider or the ability to simplify some sections harder than others, whether automatically for best accuracy or manually).