Open ChALkeR opened 5 years ago
This is, in fact, a regression between v0.6.1 and v0.6.2/v0.6.3.
v0.6.1 produces correct results:
<svg viewBox="0 0 50 30">
<path d="M0 0h50v30H0z"/>
<path fill="red" d="M10 10a1.006 1.006 0 0 0-.534 1.86 1.345 1.345 0 0 1 .715.137A1.007 1.007 0 0 0 10 10"/>
<path fill="#ff0" d="M20 10a2.126 2.126 0 0 1-1.967.686 1.29 1.29 0 0 0 1.237 1.67A1.292 1.292 0 0 0 20 10"/>
<path fill="#f0f" d="M30 10a.73.73 0 1 0-.003 1.46A.73.73 0 0 0 30 10"/>
<path fill="#0ff" d="M40 10l-.142.002c2 2 2 3.184-4.206 3.184-.054 0-.108-.002-.16-.004a4.756 4.756 0 0 0-.274 1.598c0 1.088.364 2.09.974 2.892.224-.062.46-.096.704-.096a2.6 2.6 0 0 1 2.524 1.948c.19.024.384.034.58.034a4.76 4.76 0 0 0 3.098-1.136 2.59 2.59 0 0 1-3.006-2.552 2.584 2.584 0 0 1 4.67-1.522A4.778 4.778 0 0 0 40 10"/>
</svg>
v0.6.2 (in https://github.com/svg/svgo/commit/1b0051ad1ca410f040b7bd6af7a6e5ec9c1370c1) breaks the third curve, producing the following result:
<svg viewBox="0 0 50 30">
<path d="M0 0h50v30H0z"/>
<path fill="red" d="M10 10a1.006 1.006 0 0 0-.534 1.86 1.345 1.345 0 0 1 .715.137A1.007 1.007 0 0 0 10 10"/>
<path fill="#ff0" d="M20 10a2.126 2.126 0 0 1-1.967.686 1.29 1.29 0 0 0 1.237 1.67A1.292 1.292 0 0 0 20 10"/>
<path fill="#f0f" d="M30 10a.73.73 0 1 0 0 0"/>
<path fill="#0ff" d="M40 10l-.142.002c2 2 2 3.184-4.206 3.184-.054 0-.108-.002-.16-.004a4.756 4.756 0 0 0-.274 1.598c0 1.088.364 2.09.974 2.892.224-.062.46-.096.704-.096a2.6 2.6 0 0 1 2.524 1.948c.19.024.384.034.58.034a4.76 4.76 0 0 0 3.098-1.136 2.59 2.59 0 0 1-3.006-2.552 2.584 2.584 0 0 1 4.67-1.522A4.778 4.778 0 0 0 40 10"/>
</svg>
v0.6.3 (in https://github.com/svg/svgo/commit/0f599b670da77de81eeacacd71dc335f9bdab1a8) breaks the remaining 3 curves (swapping some 0s with 1s):
<svg viewBox="0 0 50 30">
<path d="M0 0h50v30H0z"/>
<path fill="red" d="M10 10a1.006 1.006 0 1 0-.534 1.86 1.345 1.345 0 0 1 .715.137A1.007 1.007 0 0 0 10 10"/>
<path fill="#ff0" d="M20 10a2.126 2.126 0 0 1-1.967.686 1.29 1.29 0 0 0 1.237 1.67A1.292 1.292 0 1 0 20 10"/>
<path fill="#f0f" d="M30 10a.73.73 0 1 0 0 0"/>
<path fill="#0ff" d="M40 10l-.142.002c2 2 2 3.184-4.206 3.184-.054 0-.108-.002-.16-.004a4.756 4.756 0 0 0-.274 1.598c0 1.088.364 2.09.974 2.892.224-.062.46-.096.704-.096 1.216 0 2.236.826 2.524 1.948.19.024.384.034.58.034a4.761 4.761 0 0 0 3.098-1.136 2.589 2.589 0 0 1-3.006-2.552 2.584 2.584 0 1 1 4.67-1.522A4.778 4.778 0 0 0 40 10"/>
</svg>
For M 0,0 C -0.405,0 -0.731,0.33 -0.731,0.729 -0.731,1.134 -0.405,1.46 0,1.46 0.402,1.46 0.728,1.134 0.728,0.729 0.728,0.33 0.402,0 0,0
, the returned angles are:
[1.5666969669518132, 1.5752774941371457, 1.568056459652197, 1.5707955025384717, 1.5663198734556092]
Replacing those with Math.PI / 2
, which is very close:
[1.5707963267948966, 1.5707963267948966, 1.5707963267948966, 1.5707963267948966, 1.5707963267948966]
Solves the issue for the third curve. Perhaps something sign-related or otherwise caused by rounding is going wrong?
Commenting out this line: https://github.com/svg/svgo/blob/ee065be5a88c85b976db601c13eb6e55650a7d68/plugins/convertPathData.js#L343 fixes the remaining 3 curves (and #1074).
I understand that this is not the real fix, but this is an indication of what exactly is going wrong.
Disabling if (angle > Math.PI) arc.data[3] = 1;
fixes a similar issue I have as well. Hope that helps validate your theory.
@himedlooff as a better workaround, just using --config='{"plugins":[{"convertPathData":{"makeArcs":false}}]}
(or specifying equivalent option in the configuration file) would also fix the problem with less risks of introducing more potential issues. It would disable the curve-to-arc transform completely though.
Yeah it's definitely not a good way to go forward but it was the only way I could test to make sure that my issue was with svg and not something local. Also for some reason I couldn't get the makeArcs property work in my set up:
☝️ that does not fix the issue for me. 🤔
Input:
Command:
Output:
Input screenshot:
Output screenshot:
Each one of those four curves seems to break.
Version: