Closed trholding closed 2 weeks ago
Yes number precision saves quite a bit with svgs.
with regex
search:
(\d*\.\d{1})\d*
replace:
$1
reduces it to 1 decimal and (\d*\.\d{2})\d*
would reduce it to 2..
or you can do it with sed
for f in *.svg; do sed -i -E -e 's|([0-9]+\.[0-9]{2})[0-9]+|\1|g' "$f" ; done
The SVGO config file I use for svg animations to reduce their size say around 33% on average is:
svgo.config.js
module.exports = {
multipass: true,
plugins: [
{
name: 'preset-default',
params: {
overrides: {
cleanupNumericValues: false,
removeViewBox: false,
removeHiddenElems: false,
moveElemsAttrsToGroup: false,
moveGroupAttrsToElems: false,
},
},
},
],
};
this is part of a script I use to the svgo part to optimize svg sizes without affecting svg animations.
nice parallel -j2 --ungroup svgo --config ~/Documents/appimages/svgo.config.js -f {} -o . ::: .
I learned from vtracer is that polygons are significantly smaller than splines for paths. So for that use
for f in *.png; do vtracer-linux -i "$f" -o "${f%%.*}.svg" -f 2 -p 7 -g 16 -m polygon; done
Closing as svgo in a pipeline can be used. Also this is probably not relevant for the current version.
The google page example on your blog is about 117kb, using https://jakearchibald.github.io/svgomg/ one can get the size down to ~50kb and even 35k when number precision is 1 and transform precision is 0. It would be a good idea to have a --svgo option to output optimized svg with sane options.