Closed JeppeKlitgaard closed 2 years ago
interesting, thanks for the report. we shall take a look
I've found an even more minimal example:
<svg xmlns="http://www.w3.org/2000/svg" id="emoji" viewBox="0 0 72 72">
<defs/>
<path fill="#92d3f5"
d="
M11.011,11
L61,11
A0 0 0 0 1 61,11
L61,60.767
Z"/>
</svg>
thanks. Whatever is happening, I believe the code simply should bail out of attempting to reuse the svg paths that we fail to normalize.
I'm working on a quick PR that introduces a test. Would it be acceptable to fix this issue by simply converting the definite positive in the assertion to >= 0
?
i'm not sure that's the right fix, but feel free to send a PR! We'll take a look
That A0 0 0 0 1 61,11
arc coming right after L61,11
look very suspicious. What does it look like when rendered? Does it even paint?
Admittedly I know very little about SVG. The full SVG is: https://openmoji.org/library/emoji-1F5FE/
Not sure if that particular path is actually rendered though?
I am trying to use
nanoemoji
to compile the OpenMoji set into a font, but I am running into issues with a particular SVG that triggers the assertion error:line_length 0.0 must be > 0
.I have managed to narrow it down to the
1F5FE
emoji and produce the following minimal example of the fault:example.toml
1F5FE.svg
When run with
nanoemoji example.toml
it gives the following output:Running
picosvg 1F5FE.svg
doesn't lead to an error.I don't fully understand why we need to assert that the line length must be positive. Was the intention perhaps assert that the distance was not negative? Removing the
assert
statement doesn't lead to any other errors.