Size increasement

Question

Size increasement

Mister-Hope opened this issue 5 months ago · 16 comments

After upgrading to 3.2.0, a lot of my icons are getting increasement after optimizing:

Is it a bug or svgo choose to do so, how should I do to call svgo from command line targeting the minimal size? (Standard is not my primary target, but size is because my project has size limitations)

Answer 1 · 2024-01-02T09:30:31.000Z

Could you share the SVG with us, your SVGO config, and the previous SVGO version you were using that worked as expected?

Immediately, it looks like you had noSpaceAfterFlags enabled on convertPathData before, and now it isn't. Can you double-check your SVGO config? If you don't have one, then please create the following in the same directory you're executing from and try again.

svgo.config.js

module.exports = {
  plugins: [
    {
      name: "preset-default",
      params: {
        overrides: {
          convertPathData: {
            noSpaceAfterFlags: true
          }
        }
      }
    }
  ]
}

PS: This information is requested in the template you should've been presented. Please use the bug report template, otherwise it's difficult to help you.

Answer 2 · 2024-01-02T12:40:58.000Z

sorry for not following the template, I always install it globally and use it as a bin in command line, never create any config files ever.

So I am only 90% sure I previously on 3.1.0.

SO is there any way for me to revert the previous behavior though command line?

Answer 3 · 2024-01-02T14:12:54.000Z

never create any config files ever.

That's interesting, it does look as if it could find a config before.

If you're on macOS or Linux, you probably have a command called find. Could you try the following and see if it has results?

find / -name "svgo.config.*" 2> /dev/null

So I am only 90% sure I previously on 3.1.0.

If you uploaded your SVG I can say with more certainty, but from what I see right now, SVGO v3.1.0 with the default settings was supposed to include those spaces to begin with. (Though we could try to infer this setting based on usage, or only apply the change if the string became shorter, which is a separate issue.)

SO is there any way for me to revert the previous behavior though command line?

You can create an SVGO config file in the same directory you're trying to execute it in, or anywhere else if you point to in with the --config argument. It should contain the following content:

svgo.config.js

module.exports = {
  plugins: [
    {
      name: "preset-default",
      params: {
        overrides: {
          convertPathData: {
            noSpaceAfterFlags: true
          }
        }
      }
    }
  ]
}

To reiterate, please either provide the SVG or a minimal example that produces the same issue, then I can take a deeper look. I will not debug from a screenshot.

Answer 4 · 2024-01-02T14:44:48.000Z

Here are my svg files, currently I am away from my computer and I am communicating with my phone, I will check if I have any config files later and give an update here, thanks again for your help.

Answer 5 · 2024-01-02T14:44:56.000Z

https://github.com/inNENU/resource/tree/main/data/icon

You may check the recent file history

Answer 6 · 2024-01-02T15:03:51.000Z

I've tested with this:

https://github.com/inNENU/resource/blob/c31036b5d250d8b471f60df7ee5b8f491ae3471e/data/icon/weather/night/03.svg?short_path=cc66228

SVGO v3.1.0 and SVGO v3.2.0 produce the same result in both scenarios:

Default config (which makes the file larger)
The proposed config in my comment above (which makes the file smaller)

Please take your time and try to figure things out once you're on your PC. You can come back to this ticket once you have an understanding of your environment before and after, and can reproduce the issue. It's better to provide more information later, than to provide incomplete information sooner.

For example, try to go back to version v3.1.0 and see the result, etc.

Later, I'll review if we should add some logic to skip updating the path if we've made it larger, or potentially see if there are any consequences on enabling noSpaceAfterFlags by default.

Answer 7 · 2024-01-03T05:39:13.000Z

I actually noticed this too in https://github.com/twbs/icons, especially for the svg sprite icon. I haven't set up a size action because the icons are thousands but the zip file increased after 3.2.0 but 0.1 MB.

The dist file changes are as separate commits in this branch https://github.com/twbs/icons/pull/1897/commits and the config is here.

Answer 8 · 2024-01-03T12:28:37.000Z

@XhmikosR Could you please confirm if my testing methodology is correct?

# temp directory to dump SVGs
TEMP_DIR=$(mktemp -d)

# clone the repo and move into it
git clone git@github.com:twbs/icons.git
cd icons

# copy the files in the default branch to the "before" directory
cp -r icons $TEMP_DIR/before

## switch to the branch with the issue
git switch xmr/prepare-1113

# copy the files in the default branch to the "after" directory
cp -r icons $TEMP_DIR/after

# head over to the new folders we copied the icons too
cd $TEMP_DIR/after

# iterate each file in the after directory, and log if it's bigger than the pairing file in the before directory
for FILE in *; do if [ $(wc $FILE -c | awk '{print $1}') -gt $(wc ../before/$FILE -c | awk '{print $1}') ]; then echo $FILE; fi; done;

cd ../before
COUNT=0

# iterate each file in the before directory, and increase COUNT by the difference in bytes between the before and after
for FILE in *; do (( COUNT += $(wc $FILE -c | awk '{print $1}') - $(wc ../after/$FILE -c | awk '{print $1}') )); done;

echo $COUNT

I've checked a few manually, and they all look smaller. I then wrote the script above, which returns 0 results for larger files. The output of COUNT is 35546, which means we're saving 35.546 KiB across all files.

Looking at bootstrap-icons.svg separately:

git switch main
wc bootstrap-icons.svg -c
git switch xmr/prepare-1113
wc bootstrap-icons.svg -c

The bootstrap-icons.svg file goes from 1.133 MiB to 1.098 MiB. A saving of 35.543 KiB.

the zip file increased after 3.2.0 but 0.1 MB

The changes may have led to the SVGs having poorer compression from archiving tools, but the SVGs themselves are smaller, unless I tested the wrong files/branch.

Answer 9 · 2024-01-03T12:48:11.000Z

@SethFalco I still have other problems in my case, I confirm that I have no svgo config files in my project folder or any parent folder. Also I checked my user folder at C:\Users\Mister-Hope

Is there any places else where svgo could read when running on windows from command line?

Answer 10 · 2024-01-03T12:51:34.000Z

The other issue is that when I was trying to rerun on my pc using svgo -f ./ for the minified svgo files. some of the files changed:

After:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1024 1024"><path fill="#FF5656" d="M913.082 285.624A220.765 220.765 0 0 0 735.73 108.27a1243 1243 0 0 0-219.494-20.489h-10.217a1243 1243 0 0 0-219.547 20.542 220.765 220.765 0 0 0-177.353 177.352 1243 1243 0 0 0-20.647 221.03v7.2q.317 110.541 20.647 221.082a220.765 220.765 0 0 0 177.3 177.353c74.858 13.712 149.77 20.594 224.63 20.594a1244 1244 0 0 0 224.681-20.647 220.765 220.765 0 0 0 177.353-177.353c13.765-74.859 20.594-149.717 20.594-224.63 0-74.91-6.882-149.77-20.647-224.681z"/><path fill="#FFF" d="M756.376 257.141c0-16.094-15.352-12.07-20.117-7.306-9.212 9.9-33.406 30.07-85.13 40.712a105.3 105.3 0 0 1-23.823 2.541c-24.935 0-45.847-8.047-69.724-17.576-27.53-10.641-58.658-22.765-101.223-22.765-3.653 0-7.306 0-10.959.37-46.218 2.224-86.188 22.395-115.2 37.43-8.47 4.235-17.047 8.418-25.676 12.441l-2.542-6.194-.37-.37a18.74 18.74 0 0 0-24.565-9.9 18.2 18.2 0 0 0-9.9 10.27 19.27 19.27 0 0 0 0 14.294L458.212 763.63c2.912 6.989 9.53 11.383 17.259 11.383a18.74 18.74 0 0 0 17.258-26.047l-65.382-154.747a105.35 105.35 0 0 1 63.106-47.33c11.33-2.912 23.082-4.764 35.947-4.764 24.565 0 48.388 5.505 73.694 11.382 23.082 5.135 46.588 10.588 69.67 10.588 34.836 0 61.624-12.07 84.707-37.747a18.5 18.5 0 0 0 1.853-5.823V257.088z"/></svg>

Before:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1024 1024"><path fill="#FF5656" d="M913.082 285.624A220.765 220.765 0 0 0 735.73 108.27a1243 1243 0 0 0-219.494-20.489h-10.217a1243 1243 0 0 0-219.547 20.542 220.765 220.765 0 0 0-177.353 177.352 1243 1243 0 0 0-20.647 221.03v7.2q.317 110.541 20.647 221.082a220.765 220.765 0 0 0 177.3 177.353c74.858 13.712 149.77 20.594 224.63 20.594a1244 1244 0 0 0 224.681-20.647 220.765 220.765 0 0 0 177.353-177.353c13.765-74.859 20.594-149.717 20.594-224.63 0-74.91-6.882-149.77-20.647-224.681z"/><path fill="#FFF" d="M756.376 257.141c0-16.094-15.352-12.07-20.117-7.306-9.212 9.9-33.406 30.07-85.13 40.712a105.3 105.3 0 0 1-23.823 2.541c-24.935 0-45.847-8.047-69.724-17.576-27.53-10.641-58.658-22.765-101.223-22.765-3.653 0-7.306 0-10.959.37-46.218 2.224-86.188 22.395-115.2 37.43-8.47 4.235-17.047 8.418-25.676 12.441l-2.542-6.194-.37-.37a18.74 18.74 0 0 0-24.565-9.9 18.21 18.21 0 0 0-9.9 10.27 19.27 19.27 0 0 0 0 14.294L458.212 763.63c2.912 6.989 9.53 11.383 17.259 11.383a18.74 18.74 0 0 0 17.258-26.047l-65.382-154.747a105.35 105.35 0 0 1 63.106-47.33c11.33-2.912 23.082-4.764 35.947-4.764 24.565 0 48.388 5.505 73.694 11.382 23.082 5.135 46.588 10.588 69.67 10.588 34.836 0 61.624-12.07 84.707-37.747a18.5 18.5 0 0 0 1.853-5.823V257.088z"/></svg>

Any ideas how this happends?

Answer 11 · 2024-01-03T12:57:05.000Z

@Mister-Hope

I confirm that I have no svgo config files in my project folder or any parent folder.

Technically, that makes sense now. SVGO is acting as if it can't find a SVGO config file now. But to get the results you had before, it should've required an SVGO config file to specify those additional optimizations.

Is there any places else where svgo could read when running on windows from command line?

Let's not worry about that. For now, could you to please define an SVGO config file and work with that, and in a future version we'll refrain from updating the path if it becomes longer?

You can specify the config that I gave you in a previous message.

Any ideas how this happends?

That's just one of the new optimizations that was introduced in SVGO v3.2.0. Looks to me that it's probably #1873, which reduces the precision of the radius of circular arcs if is has a negligible impact on the sagitta. That's intentional and should yield no difference in rendering.

You can read the Wikipedia page for more info:

https://en.wikipedia.org/wiki/Sagitta_(geometry)

I've also opened your before and after in a browser and can confirm, there is no change in rendering. It just had more precision than what was needed.

Answer 12 · 2024-01-03T13:52:48.000Z

thanks for the reply, I am just curious why an optimized file can still be optimized again, that should be a bug?

i am not worrying about the optimized result would change.

Answer 13 · 2024-01-03T14:22:32.000Z

I am just curious why an optimized file can still be optimized again, that should be a bug?

in general, some optimizations lead to other optimizations, but they don't go in order by default so they can't work.

in the specific case of sagitta optimizations, admittedly if you run it multiple times in some cases it will decrease. that it because it calculates error relative to the original. i could modify the code to calculate error relative to the last one, simulating multipass behavior, although that might cause some visible impact.

Answer 14 · 2024-01-03T15:06:40.000Z

I am just curious why an optimized file can still be optimized again, that should be a bug?

Sorry, I misunderstood that comment. I thought you just wanted an explanation of what optimization had taken place, as I didn't realize it was two subsequent executions.

Indeed, it's as KTibow said. We try to optimize perfectly right away to avoid cases like this, and will dedicate more time to ensuring this consistency in future. Some of our plugins are more prone to this than others, and it's just difficult to enforce against right now.

What you reported is a technically a bug, but is just being treated as a quirk in the short term. Our goal is to hopefully deprecate multipass by improving how each plugin runs independently and optimizing plugin order:

remove multipass option and make all plugins deterministic and idempotent

— #1429

Once we've tackled some of our more significant issues and improved performance, we will take a deeper look at this. Thanks for raising the issue.

Answer 15 · 2024-01-03T15:11:32.000Z

@XhmikosR Could you please confirm if my testing methodology is correct?

Thanks for the reply, I really appreciate it. It seems I misread the results as everything is indeed smaller with 3.2.0.

I checked again and the zip file size is down by 0.2MB and the svg-sprite brotli size is also smaller. gzip might be slightly bigger but the difference is marginal.

EDIT: just released icons v1.11.3 https://github.com/twbs/icons/releases/tag/v1.11.3 that's using svgo 3.2.0.

Answer 16 · 2024-03-01T22:34:40.000Z

I've looked into this, and opted not to take action.

Overall, the issue is resolved by setting the noSpaceAfterFlags option to true. I don't think it's worth adding a check to only set the path if it's become smaller, as other factors play into it too, namely transforms, and the option already achieves the desired result.

Meanwhile, we won't change the default value of the option or work around it outside the config because of the issue described in:

#1138