Example Usage on nanosvg home page run with example file drawing.svg creates excess path->pts due to 'z' cmd at end. My fix below.

[KariGordon]

Example: Creates three extra points at end due to the 'z' cmd (which tries to draw a straight bezier back to start point).
for (NSVGshape* shape = image->shapes; shape != NULL; shape = shape->next) {
for (NSVGpath path = shape->paths; path != NULL; path = path->next) {
for (int i = 0; i < path->npts - 1; i += 3) {
float p = &path->pts[i * 2];
drawCubicBez(p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]);

The FIX I use is:
static void nsvg__lineTo(NSVGparser* p, float x, float y)
{
float px,py, dx,dy;
if (p->npts > 0) {
const float tol = 1.0e-5;//magic number
px = p->pts[(p->npts-1)*2+0];
py = p->pts[(p->npts-1)*2+1];
dx = x - px;
dy = y - py;
if (fabs(dx) > tol || fabs(dy) > tol) {
nsvg__addPoint(p, px + dx / 3.0f, py + dy / 3.0f);
nsvg__addPoint(p, x - dx / 3.0f, y - dy / 3.0f);
nsvg__addPoint(p, x, y);
}
}
}

[oehhar]

Hi Kari,
thanks for your great proposal. Please allow me to try to understand.

So, your proposal is in file nanosvg.h to replace
nsvg__lineTo
by your solution.
The idea is to only draw, if the dx and dy is above a given limit (1.0e-5). Where does this value comes from?
As items may be scaled, a fix limit does not feel so right.

I try to follow the usage for this change.
I was not able to locate the file "drawing.svg".
What is exactly the artefact?

If it is a drawing issue, I would expect to patch the rasterizer. Only the rasterizer knows the scale of the svg used.

Sorry for my probably dump thoughts...
Harald

[KariGordon]

Hi Harald,
In the example code the tolerance, tol, is commented as a mgiac number: That value should be modified to a better value by a developer who wants to commit the change. I used (1.0e-5) because it suits my needs.
In the example drawing.svg (which is included in the download):
<path
style="fill:...
d="m 131.73911,422.01626 c 0,146.85769 43.82213,215.39128 201.5818,141.96244 157.75968,...... 131.73911,422.01626 z"
The above line creates a series of connected cubic beziers of which the last (just before the z) will have 131.73911,422.01626 repeated three times at the end, unless the fix I propose is present.
BR Kari

[memononen]

The spec says the zero length segment is expected: https://www.w3.org/TR/SVG2/paths.html#PathDataClosePathCommand

[KariGordon]

Hi Mikko,
Ok. I personally do not want zero length segments. I want to read svg closed curves and drop them on CAD geometry. Cad geometry generally does not like zero length segments (though with NURBS it is ok). I still think avoiding zero length segments is still better: my personal opintion.
BR Kari

[memononen]

I understand. You very likely need to convert the float data to your own representation and that is a good place to check for the zero length segments and other degenerate data that you might not want to handle.