* spawn a web server and open a printable view of the design in the user's web browser
* configurable inclusion of client and operator views
* editable fields for color names, client, title, and purchase order number
* groundwork laid to save these parameters back into the SVG
* major refactor of codebase to support printing
* code is organized logically into modules
* added inkstitch logo and branding guidelines
* l10n text extraction now handled by babel
* removed legacy embroider_update extension
* partial fix for #125
* os.execv doesn't replace the process on windows
* fix simulate/params crash
* pyinstaller windowed mode breaks things?
* fix output routing for windows
* properly route stderr to inkscape too
* don't print unless there's something to print
* remove last backup version if necessary
* add documentation for Windows build
This is a stopgap measure to prevent the extension from infinitely looping
if the user mistakenly gives a zero or negative value for zig-zag spacing
or running stitch length.
It's definitely not ideal -- the user is still allowed to enter invalid
numbers, but the extension just interprets any zero value as 0.01. In
the future, I'll refactor things to add proper bounds-checking for
parameters and limit the values that can be entered in the UI.
* Simulate now works regardless of the output format you chose when you ran Embroider.
* Simulate (and the preview in Params) now respects TRIMs.
* Inkscape restart required (embroider.inx changed).
This one kind of grew in the telling. #37 was a theoretically simple bug, but in reality, the code necessary to fix it was the straw that broke the camel's back, and I had to do a fair bit of (much needed) code reorganization. Mostly the reorganization was just under the hood, but there was one user-facing change around the Embroider extension's settings window.
Way back in the day, the only way to control things like the stitch length or satin density was through global options specified in the extension settings. We've long since moved to per-object params, but for backward compatibility, ink/stitch defaulted to the command-line arguments.
That means that it was possible to get different stitch results from the same SVG file if you changed the extension's settings. For that reason, I never touched mine. I didn't intend for my users to use those extension-level settings at all, and I've planned to remove those settings for awhile now.
At this point, the extension settings just getting in the way of implementing more features, so I'm getting rid of them and moving the defaults into the parameters system. I've still left things like the output format and the collapse length (although I'm considering moving that one too).
* adds new options to Params: "TRIM after" and "STOP after"
* adds tooltip support to Params
* inkstitch now includes libembroidery and can directly output any supported file type
* this avoids the need for `libembroidery-convert` and compiling embroidermodder!
* TRIM support for DST format (inserts 3 JUMPs)
* STOP command supported as an extra color change that the operator can assign to code C00
* TRIMs cause the following jump stitch not to be displayed in the Embroidery layer
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.
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.
The Embroidery Params filter now pops up a full GTK dialog. This alows it to
load existing values in the selected shapes and present them to the user. The
user can also load and save presets.
If selected shapes have differing values for a given param, the values are
presented in a dropdown so the user can select one to apply to all.
This lets us auto-fill regions with holes in it. Just cut the region exactly
along the fill angle to convert a region with a hole to a region without.
This:
__________________
| |
| ______ |
| | | |
| | | |
| | | |
| |______| |
|__________________|
Becomes this:
__________________
| |
| ______ |
| | | |
| | | |
===== | |
| |______| |
|__________________|
The cut ( ===== ) is less than the width of the row spacing. Any connecting
stitch that follows this path becomes hidden among the rest of the fill --
an extra row of stitching isn't visible so long as the staggers line up.
Lex Neva