Rounding near zero for improved optimization
Created by: pborunda
Here are 2 real world example where "rounding near zero" is beneficial for further optimization. I did a google search for svg and borrowed these 2 png files with many curves, and converted them to svg with Inkscape.
ship.svg can squeezes an additional 1.5kb and squirrel.svg an additional 0.56kb
Sample difference for ship.svg
Activity
Created by: pborunda
Created by: pborunda
explanation of zip files above c1p4k (--set-c-precision 1 --set-precision 4...) c0p4k (--set-c-precision 0 --set-precision 4...) min (baseline file after cleanup with --strip-xml-prolog --strip-xml-space --remove-metadata --indent=none --enable-comment-stripping --enable-id-stripping --enable-viewboxing) PASS2 (result after rerunning the first pass through the same optimization --set-c-precision 0 --set-precision 4)
mentioned in issue #139
Created by: Ede123
OK, I looked at the samples and I'm very skeptical about this... I assumed this option would basically smooth out curves without influencing visual appearance very much. Instead it happens way too often that control points completely change their position/direction and the resulting shape looks nothing like the original shape!
While this might not seem so severe for traced images it's a total show stopper for properly crafted SVG files.
Remember: Scour should reduce the size of SVGs while ideally not altering visual appearance. The option you suggest will almost certainly change visual appearance. If size is that important you in these cases is suggest to improve the parameters in the tracing step so it produces better results with fewer nodes (or even improve the tracing algorithm to produce size-optimized output - obviously not an easy task, though) which will certainly produce better results than throwing out information in the end will.
added enhancement wontfix labels
Created by: pborunda
show stopper? This option is for --set-precision 0, which is basically --set-precision 1 with added option round near zero, cant affect any higher level precision settings. Can you provide further detail how you came to this conclusion with example svg. Thanks for the tip about inkscape setting to reduce number of nodes, i use it often. very useful!
Created by: Ede123
You provided the sample SVG... Open it in Inkscape, select the path, activate the node tool and press "Ctrl+A" to select all nodes. You should then be able to see control point handles and you should quickly notice that some of them (where the "rounding near zero" occurred changed their position completely. Also note for example that the paths that were optimized to be perfect circles at the railing of the ship are now some rounded parallelograms.
I don't see a use case where this loss in precision would be acceptable.. Where scouring, not chopping!
Created by: pborunda
I'm comparing ship.c1p4k.min.svg (13593bytes) and ship.c0p4k.min.svg(12088bytes) in browser full size (-1505 bytes). These 2 images are the only ones that matter in the comparison. The other images are for your reference. I don't see the jump as you describe. As for use case, I'm an end user of this the scour tool and I'm using it in my web application. Most of my images are micro sizes, so at most 64px height with most viewbox 100x100. My target platform is an embedded web server so any KB saving are appreciated, I've using several other minification/compression tools like uglifyjs, google closure compiler, purifycss, etc. I cannot use png as my svg are styled and interactive.
Created by: Ede123
Well, as said before: If file size is that important optimize the creation step.
If you're really using traced SVGs in you web app, then this is the part were you can reduce file size best, as traced path data is huge. You could try "Strg+L" in Inkscape. It's usually changing the visual appearance of a path significantly, but it reduces the number of points and therefore size of the path, so it might be a solution for you specific use case.
mentioned in issue #141
