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.
Thanks for sharing. It's hard to find good stand-alone SVG editing libraries/engines that really focus on the back-end editing/API and not the UI (buttons, icons, etc). We've always wanted an engine that just focuses on draw and export of the SVG, and that lets us define the buttons, look, UI etc. as needed.
Perhaps of interest, one of our devs poked at native JS approach for a while- https://github.com/SpeciesFileGroup/svg-detailer/. It definitely needs some code cleanup prior to production readiness, but it illustrates our needs/thought process.
This will come in handy for doing quick CNC work. A lot simpler than inkscape or other similar tools especially if you just need to cut a few simple pieces.
This is amazing! I've been handwriting some simple SVGs and this makes that so much simpler. I like how this goes down pixel-level accuracy that provides the simplicity I like and exposes semantics that are familiar to programmers such as path commands.
Tools like Sketch are a little intimidating to start learning and I'm not even sure if they expose things like path commands.
This is excellent. I am probably missing something obvious but how do I load an arbitrary SVG into this? Do I need to manually extract the PATH parts of the file ?
My hobby is plotting (AxiDraw) generative art. I often want to hand tweak SVGs prior to plotting them. I often get frustrated with the heavy weight tools such as InkScape and Illustrator.
This looks like just the thing I need. Looking forward to trying it out this weekend!
Seeing this reminds me of the question: "why do we have an <img> element? Why not an <icon> element? Or an <include> element?" [1] Back in the olden times shipping a feature like the `url(path:)` above was enough to have it become a defacto standard!
Meta: link [1] uses text-fragments [2] that seem super useful to me but apparently are not implemented by Firefox (yet!)
Well, we have plenty of images already: <img>, <picture>, <figure>, <object>, <iframe> can be used for that purposes too. It is just unclear how <icon> is different from <img>.
As of <include> (so called client side includes) Sciter has them [1] as they make sense in precisely desktop environments - when files included from local sources (synchronously).
Is there a library out there that allows you to make some of these manipulations in code? Like: translateX(svg, 10px), scale(svg, 10%), ConvertToRelative(svg), AutoBounds(svg), etc.
There are many that allow you to generate an svg, but it's been hard to find those that allow you to manipulate an existing svg.
const path = new Svg('M 0 0 L 1 1');
path.translate(1, 2); // Translates (x:1pt , y:2pt)
path.scale(2, 3); // Scales (x:200%, y:300%)
path.setRelative(true); // Converts the path to use only relative commands
path.asString(); // Export the path with no minification
path.asString(1, true); // Export the path with 4 decimals, and minification
I wanted to publish them separately on npm, but didn't had time to do it :)
True, I discovered that after playing with it for a while! But it can be hard for a new person (who's not aware of the SVG commands) to to and clear that text area to clear the canvas.
I like this tool a lot. As someone who learned modelling in Autodesk Inventor then had to re-learn in Maya, a tool like this could help to make the transition from a hard, grid based system to something much more artistic and flexible.
Unbelievable. I just wrapped up my first svg-heavy project. Something like this would have been an invaluable learning tool. I ended up writing a lot of SVG by hand, and mostly through trial and error.
Cool. But weird interaction style - with having to hover over the vertical bar below the fields in order to change field to be editable. Curious why one would create fields that way.
This is super cool. I’ve heard people talk about how you can manually editing SVGs but it always looked impossible to me. This does an awesome visually showing you how it all works.
I typically manually edit svgs in inkscape, but it's a real hassle:
- copy/paste-in-place introduces minor deviations.
- I can never be sure if copy/paste/move will change path values or do it as a transformation.
- I don't do it often and forget to turn off path auto-minification; it's a real pain to have inkscape constantly shift between relative accumulating coordinates and absolute coordinates.
Very nice! I've needed an easy to use SVG editor for making simple icons before, especially with grid snapping, and wasn't able to find anything like this.
The main drawback for those things is that you cannot parameterize them, which is a bummer if you've created a shape that you might want to vary in ways that a transform cannot easily do.
For styling purposes, yes, CSS allows a lot and things like currentColor enable you to at least have colors and styling dynamic when instancing symbols. But things like parametric shapes don't work without scripting, which is a bummer, since in many other places SVG is very amenable to handwriting with a lot of cool features. Just not with a lot of abstraction options.
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).