SFSymbols generation mismatch to original SVG

[vladzz]

Hey Team,

Great tool and I have started using it in my workflows a lot. I have found a strange bug when generating SFSymbols from SVG's that my designer has provided. I have provide examples.

Original SVG:

Generated SFSymbols:

You can see that it fills the path in the file in the top right-hand corner. I have tried another tool which doesn't cause this problem. So thought I would highlight it out for your team. Hopefully a simple fix.

Thanks,

@vladzz

[swhitty]

Thank you @vladzz for reporting the issue.

It now should be resolved in 0.16.0 if you are using macOS

[kmck]

hey there! this library is a delight. i just happened to install 0.16.0 and noticed that the fix for this seemingly breaks some SVG conversions that were previously working as expected in 0.15.0.

i'm still digging in, but at first look it would seem like a single path that has a "hole" gets rewritten in a way that removes the hole:

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
>
  <g fill="black">
    <path
      fill-rule="evenodd"
      d="m11.976 21.966.027.036.023-.031 2.222-2.72 3.213-3.901.006-.007 1.107-1.356h-4.307l-.235-1.726c-.105-.768-.312-2.411-.527-4.113-.265-2.095-.54-4.28-.65-5.035l-.015-.102-.004-.104A.954.954 0 0 0 12.003 2a.954.954 0 0 0-.833.907l-.004.104-.015.102c-.11.755-.385 2.94-.65 5.035-.215 1.702-.422 3.345-.527 4.113l-.235 1.726H5.433l4.3 5.261.006.008 2.237 2.71ZM8.194 20.52l2.212 2.678a1.992 1.992 0 0 0 3.194 0l2.187-2.678 3.22-3.907 2.186-2.679c.885-1.057.467-1.941-.933-1.941h-4.252c-.097-.718-.301-2.33-.515-4.022a474.46 474.46 0 0 0-.664-5.144A2.949 2.949 0 0 0 12.003 0a2.949 2.949 0 0 0-2.826 2.826c-.11.754-.395 3.012-.664 5.144a597.198 597.198 0 0 1-.515 4.022H3.722c-1.376 0-1.794.884-.91 1.941l5.382 6.586Z"
      clip-rule="evenodd"
    />
  </g>
</svg>

[swhitty]

Thank you @kmck 0.16.2 should include the fix

[kmck]

works great! thank you