Svgo: [Bug] Arc path too compressed for Illustrator/Affinity

[etltn]

Using the (default) option to rewrite the path on [email protected] an arc is wrote as:
a.65.65 0 011.109-.459

This is properly displayed on Chrome and Firefox but some editors (I've tryed Adobe Illustrator CC 2019 and Affinity Designer 1.7) are not able to recognize the large-arc-flag parameter.

011.109 are 3 values:

• 0
• 1 (a boolean is required here, it cannot be 11.109)
• 1.109

Illustrator and Affinity are not enough smart to understand that.

How should be:
a.65.65 0 0 1 1.109-.459 (there are 2 more spaces)

Attached a full example:
example.zip

[GreLI]

Just disable noSpaceAfterFlags in convertPathData plugin.

Example config

YML:

plugins: 
  - convertPathData:
      noSpaceAfterFlags: false

JSON:

{
  "plugins": [
    {
      "convertPathData": {
        "noSpaceAfterFlags": false
      }
    }
  ]
}

[grig0ry]

I think this option should be disabled by default. After updating svgо to 1.3.0, several projects in production were broken. :disappointed:

[etltn]

Just disable noSpaceAfterFlags in convertPathData plugin.

It works, as @grig0ry I think noSpaceAfterFlags: false should be the default.

[GreLI]

It's a totally standard syntax from a 8-years old specification (and was introduced in a working draft a year before). If some software has a problems with it—those should be addressed to that software.

[rossmoody]

Thank you! I was having this issue where I was outputting SVG that would render fine but if I took it to SVGOMG it wouldn't be able to recognize the code. For instance:

Original:

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M12 3C10.8954 3 10 3.89543 10 5C10 6.10457 10.8954 7 12 7H12.01C13.1146 7 14.01 6.10457 14.01 5C14.01 3.89543 13.1146 3 12.01 3H12ZM12 10C10.8954 10 10 10.8954 10 12C10 13.1046 10.8954 14 12 14H12.01C13.1146 14 14.01 13.1046 14.01 12C14.01 10.8954 13.1146 10 12.01 10H12ZM12 17C10.8954 17 10 17.8954 10 19C10 20.1046 10.8954 21 12 21H12.01C13.1146 21 14.01 20.1046 14.01 19C14.01 17.8954 13.1146 17 12.01 17H12Z" fill="#353535"/>
</svg>

Optimized without no space after flags set to false

<svg width="24" height="24" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M12 3a2 2 0 100 4h.01a2 2 0 100-4H12zm0 7a2 2 0 100 4h.01a2 2 0 100-4H12zm0 7a2 2 0 100 4h.01a2 2 0 100-4H12z"/></svg>

Would turn into:

<svg width="24" height="24" xmlns="http://www.w3.org/2000/svg">
  <path fill-rule="evenodd" clip-rule="evenodd" d="M12 3a2 2 0 100 4 NaN NaNhNaNa2 2 0 100-4 NaN NaNhNaNzm0 7a2 2 0 100 4 NaN NaNhNaNa2 2 0 100-4 NaN NaNhNaNzm0 7a2 2 0 100 4 NaN NaNhNaNa2 2 0 100-4 NaN NaNhNaNz"/>
</svg>

Fix for me:

{
  "plugins": [
    {
      "convertPathData": {
        "noSpaceAfterFlags": false
      }
    }
  ]
}

[radium-v]

Just a heads up for anyone coming from #1138 - you may also have to use the noSpaceAfterFlags: false option for the mergePaths in conjunction with the one for convertPathData.

{
    "plugins": [
        { "convertPathData": { "noSpaceAfterFlags": false } },
        { "mergePaths": { "noSpaceAfterFlags": false } }
    ]
}

[davidar]

You can add librsvg to the list of software that chokes on this optimisation. If this option is going to remain enabled by default, could there at least be a warning about the incompatibility somewhere? It's not easy to track down exactly what's going wrong at the moment.

[etler]

This also breaks the default linux svg renderer which impacts all image viewers, gimp, and the file system image previews. I agree with everyone else that this should not be enabled by default because it breaks svg output in many different applications.

A default setting does not make sense if the majority of users need to override them and shipping an svg that is broken for our users in many contexts is not acceptable for my company.

[EdoardoTona]

Affinity Designer has fixed this bug on 1.8.4