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
pyinstaller packages up all of a python script's dependencies and builds them into standalone executables. It can either do a directory (containing a single executable and a bunch of shared libraries) or a self-contained executable that effectively just contains a compressed version of the directory.
The problem is, if you have several scripts like we do, you get several large directories or standalone binaries, and there's a ton of duplication between them. Fortunately it looks like using the directory method and just combining the directories works fine (for this project).
This PR runs the above build on any tagged commit and publishes a release in github containing the pyinstall-ified tarball. If the tag is named like "v1.2.3" _and_ the tag is on the master branch, then the github release will be marked as "production". Otherwise, it will be marked as a "pre-release". This means that we can build testable tarballs of the extension in a pull request by tagging a commit.
The owner of the this repo would need to go to https://travis-ci.org/profile and flip the repository switch __on__ to enable free automated flake8 testing of each pull request.
The simulation window is scaled to fill the available space on the screen. In
the Params dialog, the simulation window sits to the right of the Params window
and fills the remaining space.
There is no __sys.stderr_backup__ defined in the [Python sys] module. __save_stderr()__ adds a variable by that name which is a bit unconventional but it does work. This PR changes __restore_stderr()__ to read that data from the same variable. Without this change, __restore_stderr()__ will probably raise a NameError at runtime because __stderr_backup__ is an undefined name.
flake8 testing of https://github.com/lexelby/inkstitch on Python 2.7.14
$ __flake8 . --count --select=E901,E999,F821,F822,F823 --show-source --statistics__
```
./embroider_params.py:748:18: F821 undefined name 'stderr_backup'
sys.stderr = stderr_backup
^
```
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.
Lex Neva