Open timegrinder opened 4 years ago
For number 3: If every continguous path in a d
attribute ends with the z
command, stroke-linecaps should be omitted. But as of the version currently running on SVGOMG, this isn't done. For strokes returning to their starting point without using the z
command stroke-linecaps
but also and stroke-linejoins
attributes can make an actual difference.
[Technical detail:] Wether or not they look the same, depends on the stroke-linecaps
and the angle:
stroke-linecaps:round
, z
and non-z
returns look the same if stroke-linejoins
is also round
.stroke-linecaps
and stroke-linejoins
, z
and non-z
returns can also look the same depending of combinations of the two attributes, the departure and arrival directions (angles) and on the stroke-miterlimit
.Hi, could you please provide svg which are broken by svgo?
I don't get that question. This thread is not about SVGs getting broken.
Yeah, sorry. Not broken but not optimised. Need input and output of what you expect.
Hey there,
First off, thanks for the fantastic tool, I've been using it for years (through front-ends, so not direct experience).
While hand optimising some files after running them through I noticed a couple of things relating to styling / attributes that were left over after optimisations.
I'm still pretty new to the ins and outs of the SVG format standard, but would it be accurate to say that some special paths / shapes make some attributes redundant and candidates for automatic removal?
1) Circle having stroke-linejoin, stroke-linecap (As it's one contiguous path without corners or ends) 2) Rectangle having stroke-linecap (As it's one contiguous path with corners, meaning linejoin is valid, but no ends) 3) Continguous paths that terminate at their starting node would also not need stroke-linecap (I get this might not be computable easily, and just checking the start/end wouldn't work because some paths may be missing lines between nodes along the way) 4) Any styling of clipPath (I think I read in other issues here that SVGO can't tell if a path is inside a clipPath element to work out what it should and shouldn't clean, so this one might already be covered).
At the moment I'm getting around these by just running some RegEx replaces over my files which work fine, but wondered about these things (if they are simple) being integrated. I also apologise in advance if these are done already I was just misusing the plugins that handle them.
Thanks!