My previous fix didn't really do the job. It took patches in Z-order, but runs of patches of the same color were fed into the TSP algorithm and it could embroider them in whatever order it chose. This resulted in underlays for my fill regions being embroidered AFTER the fill.
Now, the "preserve order" option has been changed to "preserve layers". Patches on different layers are gauranteed to be stitched in layer order. Patches of the same color within the same layer can be stitched in any order as chosen by the TSP algorithm.
* properly process transform parameters (ungrouping no longer necessary!)
* handle satin on beziers properly
* previously beziers were stroked as straight line segments that included control points
* allow overriding parameters on individual paths by adding extra svg params
* embroider_angle, embroider_stitch_length, embroider_zigzag_spacing, embroider_row_spacing, etc
* set using "Edit XML"
* default to 10 pixels per millimeter
* properly write CSV files in millimeters (was dividing by 10)
* always translate pattern to origin to fit in hoop
* add "running stitch length" for < 0.5 stroke width)
* don't traceback if no paths were selected
* add "repeats" option for stroke (satin/running stitch) to go back and forth over the line
* good for a double line of center-line underlay below satin
Add Franklin G-Code target as output.
Fix issue that filled area was treated as one patch per stitch.
Don't autodetect orientation; let the user choose by orienting the object.
Remove empty stitches.
Base generated inkscape path on output from file.
Allow maximum stitch length of 10 cm.
Save debug output in /tmp.
Disable almost all debugging.
Let hatching connect the segments.
Lex Neva