Open daniel-starke opened 5 years ago
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.
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;
Thank you for the quick fix. By the way, the check for *s != 0 is in many cases redundant.
The inner arcs are straight lines instead. Any idea?
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.
I fixed it! Please check it. https://github.com/SanCheung/nanosvg/commit/f29d7055966d3c06295a8f10ea2ebbdd844d3c2e
firefox and chrome can't show the svg file, so it's not a bug. or please provide a real svg test file.
Just because it is too small to be seen does not mean that it is not there. Here is a scaled version:
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?