Output file is larger than input file

[meziantou]

Describe the bug

The output file is larger than the input file

To Reproduce

svgo --folder .\Icons\ --multipass --eol lf

input.svg (490 bytes)

output.svg (509 bytes)

Expected behavior

The output file is smaller or identical to the input file

Desktop (please complete the following information):

• SVGO Version: 3.0.0
• NodeJs Version: 19.0.0
• OS: Windows 11 (22H2)

[C0rn3j]

Still the case in 3.0.4.

It would be nice if it followed the approach of tools like oxipng, detected output is larger than input and refuse to rewrite original file, provided things like --pretty aren't defined where bigger file size is expected.

% svgo --multipass 198497422-1a4ed4ee-ff79-4141-ac44-1cc93e03e9c2.svg

198497422-1a4ed4ee-ff79-4141-ac44-1cc93e03e9c2.svg:
Done in 7 ms!
0.479 KiB + 3.5% = 0.495 KiB

[KTibow]

I don't think this should be added because

• unexpected behavior if this is on by default
• would take a long time to implement as there are so many things that could cause the output to be intentionally larger than the input (eg the option that converts all shapes to paths)
• this isn't like oxipng, we aren't dealing with raw pixels with the goal to optimize, svgo does transforms other than just optimizing
  • this would cause inconsistent behavior if you have one thing that removes bytes and another thing that adds bytes. eg if svgo expands a bunch of arcs, making the file bigger, but you were expecting the scripts inside to be removed and some attributes to be removed, this would be unexpected (but it would only happen if the increase is large enough)
• in this specific case, the reason this happens is because svgo expands the arc flags to have a space, which is good for compatibility

[C0rn3j]

unexpected behavior if this is on by default

With how complex this tool is, that's probably a completely fair point and it should be an opt-in flag.

I am ignorant of SVG's complexities and my only knowledge is that it is a plaintext file with vectors and some extra data.

this would cause inconsistent behavior if you have one thing that removes bytes and another thing that adds bytes. eg if svgo expands a bunch of arcs, making the file bigger, but you were expecting the scripts inside to be removed and some attributes to be removed, this would be unexpected (but it would only happen if the increase is large enough)

I personally am only interested in total file savings, if the tool saves 100 bytes and adds 50 bytes elsewhere, I will happily take that -50 byte change.

The why of this tool is also completely focused on removing and reducing, so saving a file of increased file size with no way to disable the behavior is a bit unexpected.

would take a long time to implement

If we take your points into consideration and focus on something simple, how about an implementation with an opt-in flag --save-if-smaller with description Only save if we reduce total file size?

That should be easy to implement while solving my concern, and likely OPs too.