The viewBox effectively adds global scaling and translation to all shapes in
the SVG. Borrowing from inkscape-silhouette, we construct a transform from
the viewBox and apply it to all objects.
When adding the stitch plan into the SVG, we need to compensate for this
implied transformation, which we do by adding its inverse as a transform
on the stitch plan polylines.
All of this allows us to do away with the nonstandard 10 pixels per mm that
was previously hardcoded into inkstitch. Old designs can add a viewBox to
switch from 10 pixels per mm to the standard 96 ppi that Inkscape uses.
Switching to a cooperative model. This has the downside that a long
patch computation will cause the simulate window to take longer to
update, but in practice the longest this will be is a couple of
seconds (for a very complicated autofill region).
The problem with this approach is that sometimes the SystemExit happens down
inside shapely and it complains bitterly (on stderr). May have to rethink.
Polylines in SVG are essentially the same thing as paths, but with no curves.
But inkscape-embroidery treats polylines as literal stitches; it does not
do satins, fills, etc but instead takes the coordinates and uses them directly
as stitches.
The advantage in this case is that one can re-run the extension on its own
output and get back the same stitch output. Why would you want to do this?
Consider the case where you have a basic embroidery machine that can only do
a 4x4" square. If you have something that's a bit bigger than 4 inches wide,
it might still fit in the square if you turn it at an angle. But working with
your entire design rotated at an angle is a total pain, and you'd also have to
rotate the angles of all the fills to compensate.
Instead, just run the extension, rotate the stitches to fit, and re-run, and
your stitch file will work on your 4x4" machine.