inkstitch / pyembroidery

libembroidery/EmbroideryFormats converted to python
MIT License
72 stars 28 forks source link

EmbEncoder converts JUMP to TRIM,JUMP #30

Closed lexelby closed 6 years ago

lexelby commented 6 years ago

This line adds a TRIM (possibly preceded by a tie-off) every time it encounters a JUMP: https://github.com/inkstitch/pyembroidery/blob/40223e4cb4a65dbee19e4b78dc97ad1f22cc773a/pyembroidery/EmbEncoder.py#L95

I can't see any way to only specify a jump without a trim.

lexelby commented 6 years ago

Also, folks that ask for a long jump with tie-on enabled, might expect tie-off before the jump and tie-on after. That's how I wrote Ink/Stitch after discussing it with wwderw.

tatarize commented 6 years ago

I think this is a serious defect. Since you can overtly request the a "sequence_break" it should actually just pass any jumps straight through without any modifications at all. If you gave one to the encoder, you must want it for some reason and the encoder should totally butt out.

In fact, if you overtly used any low level commands it should only step in if those commands might cause an issue for the particular format (and maybe not even then).

It should treat jumps much more unstitched stitches because the encoder actually overtly covers the other use for jumps, namely cutting, moving, and moving to new work.

That use for jump clearly far less accounted for in the encoder. And it might actually be prudent to give the encoder some options here. For example if a stitch is above like 50 it might actually be correct to insert a jump statement on the way to there.

We could break stitches above a certain point into smaller stitches, or throw in some jump stitches on the way there. But, if the user explicitly asked for a jump stitch, it should pass that through unmolested, unless the position is something absurdly far away or something.

tatarize commented 6 years ago

I'm thinking delete that line. Add in overt commands that specifically perform TIE_OFF and TIE_ON (the commands do nothing if the previous or next command isn't a stitch and do so rather safely). Then properly determine appropriate action to occur if a stitch is above a certain point. Just because the format permits 12.1mm stitches doesn't mean it isn't entirely reasonable to throw in some jumps to get there, and not necessarily assume it means (I want to stitch this entire segment, when it could rightly mean, I want to put my next needle hit in this location).

tatarize commented 6 years ago

I changed the API to support both methods #28 also gets likely fixed with this.

I added two overt sub-categories of stitch. NEEDLE_AT and SEW_TO hopefully this properly gives the distinction. Too Long Stitches will be divided if we used SEW_TO and if we NEEDLE_AT then we do not invent additional stitches, we fill that space with JUMP and if the machine ends up cutting it, then oh well. There's certainly some other items that might matter for that.

I removed the trim line to jump. If you told it to jump it should only actually jump.

There's also a jump_threshold which is the length at which a too long stitch will end up having jumps put in. This is true if you use NEEDLE_AT as well as if you use STITCH which decides the behavior by whether whether the max_stitch or the jump_threshold is lower, with it defaulting to your expected behavior of inserting a jump if it can't make it (generally it's for inkstitch, it should default to your expectations).

I also added overt commands for TIE_ON and TIE_OFF. if you use that it will do the action. So if you think it's right to tie-off, jump that way, then stitch further that way. You should have direct access to those elements.

tatarize commented 6 years ago

By default, too long stitches will now insert some jumps along that path. STITCH being slightly ambiguous as to the desired behavior will choose based on some notably rather confusing criteria but always default to your preferred method if unset. And there's some overt methods that kinda specify the method you want. Though, maybe it would be better off set in some other way. Like declaring preferred method of dealing with long stitches, and just not caring about the jump_threshold unless a method cares about it. Maybe even allowing it exceed max_stitch value or maybe even give another value to max_stitch that effectively means max achievable stitch. With some of the jumps you could have longer stitches but you couldn't have insanely too long of stitches especially with something like auto-trimming.

lexelby commented 6 years ago

Sounds good, thanks! I'll take a look at your changes shortly.

lexelby commented 6 years ago

This all looks great to me. Thanks for the quick fix!

pyembroidery is really looking awesome. Nice work on all this!