SVG issues

[Juerd]

This is a deliberate duplicate of #442, which should not have been closed, because that was a legitimate bug, and not a support question.

The issue f0x52 reported seems to be caused by the closepath ('z' or 'Z') command in a 2 node path. Whether closing a path makes sense for a 2 node path, might be arguable, but at least Inkscape implements simple lines like that. But remove z from the path element, and it works just fine. It might be related to colinearity, for example by backing over the intended line to close the path, but perhaps this insight may help to develop a workaround or fix.

Specifically, <path d="m 0,0 0,10 z"/> fails to generate gcode in Laserweb 4.0.990b-115-x64, while <path d="m 0,0 0,10"/> will.

[Juerd]

Note: the removal of 'z' or 'Z' works for the Inkscape drawing provided by f0x52, not for the boxes.py output.

[tbfleming]

It is a support question because it's a known issue. A closed line represents 0 area, throwing off polygon algorithms. The volunteers at https://plus.google.com/communities/115879488566665599508 know how to instruct new users how to avoid this.

[tbfleming]

Here's the problem: if I don't lock issues like that one and this one, then they'll continue to attract new users like moths to a flame.

[Juerd]

If you're looking to scare away new contributors, this would be a good way to do so.

Instead, I'd suggest leaving the issues open so similar things are reported in the right place, rather than with a new issue. Indeed you will receive fewer notifications if you scare away people who are just trying to help by closing their issues, but that will also inadvertedly filter out useful information.

[Juerd]

As for the actual issue: open paths of 2 nodes are also 0 area, but work fine. Besides that, a lasercutter application should be able to cut lines regardless of any area issues, because drawing lines is what laser cutters do, and I think the solution should be baked into the software, not a matter of "instructing users" to work around the problem.

[tbfleming]

It'd be nice if there was a good way to filter potential contributors from people who just need the support the G+ community provides.

[Juerd]

There are several issues with that.

I asked f0x52 to contribute to the process of getting the problem fixed by providing information that might be useful to you. As a developer, I absolutely welcome example input that my programs fail to deal with. Even for known issues, additional information can often lead to new insights.

Whereas you're treating the report as a user seeking help, it is actually a matter of someone reaching out to developers with information that might be useful.

In this specific case, we had been unable to find any information about the known issue. I have no idea whether the information I provided about the closepath command is new to you or was already known. For all I know it might be hidden in another closed Github issue.

[tbfleming]

It treats open paths separately since the polygon algorithms can't handle them. That handling isn't nearly as capable, so it doesn't treat closed paths that way.

[Juerd]

Still, though, the workaround might be to simply consider all 2-node paths as open, by simply ignoring the closepath (z/Z) command. This would probably solve quite a few real world cases.

[tbfleming]

f0x52's example looked exactly like mistakes new users produce until the volunteers in the community explain how to do it correctly.

[tbfleming]

That workaround is worth considering.

[Juerd]

It appears I used the wrong terminology; #442 was locked, not closed.

[tbfleming]

The advantage of locked is that it doesn't hide it from the default search. I want most new users to go through G+ first, especially with SVG issues.