💾 Archived View for dioskouroi.xyz › thread › 24998532 captured on 2020-11-07 at 00:55:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
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).
If you're interested in minifying SVGs by hand, we're creating SVG icons in under 1KB at
https://github.com/edent/SuperTinyIcons/
We could do with some help on the accuracy of some of them :-)
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.
I found a related article:
https://news.ycombinator.com/item?id=14310652
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-...
> _One request per icon as done in the README is extremely wasteful._
That depends on the transport, this is one of the things that HTTP/2 (and HTTP/3) aim to fix by downloading them in parallel in a single connection.
Watch the devtools network tab:
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.
[0]:
https://camo.githubusercontent.com/d0518022b7a02d405ad5112a0...
[1]:
https://blog.cloudflare.com/hpack-the-silent-killer-feature-...
How do guys even manage to type those path coordinates by hand ? Do you do the calculations for path coordinates mentally ? Or use keep `calc` handy.
Any Tips and Tricks would be appreciated.
That project is fantastic! I'll soon have need for some clean SVG language icons and these are perfect.
Awesome project. I shamefully admit this is a hobby of mine as well. Glad to see I am not alone.
That is just ... wow! A tiny issue: you missed the Scala icon.
Please send a pull request :-)
The few times I've needed a vector graphic quickly just typing an SVG into Vim always felt like the path of least resistance. (heh)
Thanks for the very informative post!
I wonder what you think about SVGOMG:
https://jakearchibald.github.io/svgomg/
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.
I can recommend path simplification tools built into
https://github.com/Microsoft/maker.js
Despite the repo description, it's a universally useful SVG library
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.
Hi Chrismorgan,
Could you please point me to some resource where the kind of abbreviation you show in the arc example are specified? I googled and couldn't find it.
Thanks!
A couple of useful links:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d
https://www.w3.org/TR/SVG11/paths.html#PathData
(SVG 1.1 spec) or
https://svgwg.org/svg2-draft/paths.html#DProperty
(SVG 2 spec); the two are much of a muchness.
Tools that can't parse the compressed arc flags are especially frustrating. Android Studio for example.
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.
Checkout DotGrid for writing svg graphics too. I'm not involved with the project, just love the idea of small, energy efficient software.
https://100r.co/site/dotgrid.html
Just fell down quite a rabbit hole exploring their site, some really lovely tools, and some fascinating writing
What a beautiful piece of code and UI!
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.
Thanks for sharing !
My thoughts exactly. Sometimes you need a quick SVG that is too complicated to do by hand but too simple for Inkscape.
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 ?
Very cool!
Especially for the Sciter (and now Sciter.JS [1]) where we can use SVG paths directly in CSS as vector images:
input.radio {
background-image: url(path: M 4 8 L 10 1 L 13 0);
background-size: 1em;
stroke: black;
stroke-width: 3px;
}
More details are here:
https://sciter.com/lightweight-inline-vector-images-in-scite...
[1] Sciter.JS preview:
https://github.com/c-smile/sciter-js-sdk
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!)
1:
https://diveinto.html5doctor.com/past.html#:~:text=original%...
2:
https://wicg.github.io/scroll-to-text-fragment/
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).
[1] <include> in Sciter:
https://sciter.com/forums/topic/import-html-in-html/
This is real cool!
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!
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.
Great tool, it reminds me of svg edit[0]
0 =
https://svg-edit.github.io/svgedit/dist/editor/index.html
Nice tool. I recommend adding an "clear" or "new" option where the users can clear the preset sword and start a new art.
The “Path” text area in the top left is fully reactive, so if you delete its contents the sword vanishes.
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.
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.
Looks great, though :P
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.
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.
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.
Is there such a thing as SVG but where you can define a subshape and reuse it elsewhere in the file?
Perhaps you're looking for <defs> and <use> elements?
That looks like the ticket, thanks! It's very embarrassing that I didn't know about this before.
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.
Seems like you can get pretty far with CSS variables though, yeah? Do you have a good example of something common that can't be accomplished?
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 love this. I'm too often guessing and doing trial-and-error when trying to get SVG paths juuuust right for my SVG-based virtual tabletop project.
that's a life saver. I edited them manually too many times to count and it would have been useful then.
Very cool. Although I prefer Inkscape, and it handles SVG nicely.
How is the pan-zoom implemented in this? It's nicely done.
Looks like a great alternative to Inkscape
You're right - The few times I've used Inkscape to do something simple has always resulted in remoting into my PC to use Illustrator.
How does this compare to svg edit.
Love this!!
Nice cool