Bug: complex path rendered wrong

[daniel-starke]

I tried the following SVG: <svg width="2" height="2"><path d="M.604.605L.75.922C.754.896.77.877.783.855l.356.354a.9.9 0 00-.239.535H.7c-.081-.006-.081.118 0 .111h1.1c.03 0 .055-.024.055-.054V.699A.056.056 0 001.8.643a.056.056 0 00-.055.056V.9a.9.9 0 00-.535.239L.857.785C.88.773.897.755.922.752L.604.605zM1.744 1v.674l-.463-.465A.832.832 0 011.744 1zm-.537.28l.467.464H1a.778.778 0 01.207-.465z" color="#000"/></svg> It renders correctly in Inkscape to this: But nanosvg gives me this: Maybe an issue with the path component order?

[daniel-starke]

I found the reason for this. The number parser of Inkscape seems to terminate if a leading zero is followed by something which is not a dot. Therefore, the number of components/numbers changes. I assume nsvg__parseNumber() needs to be changed accordingly to fix this issue.

[tesch1]

nice find :)

diff --git a/src/nanosvg.h b/src/nanosvg.h
index 4797afd..ecef747 100644
--- a/src/nanosvg.h
+++ b/src/nanosvg.h
@@ -1152,6 +1152,11 @@ static const char* nsvg__parseNumber(const char* s, char* it, const int size)
                if (i < last) it[i++] = *s;
                s++;
        }
+       // leading zero
+       if (*s && *s == '0') {
+               if (i < last) it[i++] = *s;
+               s++;
+       } else
        // integer part
        while (*s && nsvg__isdigit(*s)) {
                if (i < last) it[i++] = *s;

[daniel-starke]

Thank you for the quick fix. By the way, the check for *s != 0 is in many cases redundant.

[daniel-starke]

The inner arcs are straight lines instead. Any idea?

[tesch1]

that one's harder to fix, the parser incorrectly assumes all args are float, so doesnt recognize that the arc flags are only one char, so drops those two arcs as malformed.

[SanCheung]

I fixed it! Please check it. https://github.com/SanCheung/nanosvg/commit/f29d7055966d3c06295a8f10ea2ebbdd844d3c2e

[jiongt]

firefox and chrome can't show the svg file, so it's not a bug. or please provide a real svg test file.

[daniel-starke]

Just because it is too small to be seen does not mean that it is not there. Here is a scaled version: