Support adding tabs

[tytouf]

jscut is awesome and would be even greater if it could support the inclusion of tags to prevent the piece from floating on the cut table when separated from the raw material.

Ideally it should be possible to add tags manually and hand pick each tag position or they could be part of the svg file as specific elements (discriminated by name or id for instance). The tags height can be edited as a global parameter.

[peteruithoven]

@tytouf could you help out designing this? What kind of tab related options do you think are necessary? How would handpicking work? How would you like jscut to select / recognize tabs in a existing file?

Is is tags or tabs btw?

Maybe a first iteration could simply involve options like:

• Enable tabs (checkbox)
• Tab depth
• Tab width
• Minimal distance
• Maximum distance Maybe all the options except Enable tabs should be in a fieldset that's normally closed/folded.

[tbfleming]

I've always heard it called tabs, but I don't know if it's standard terminology or just common.

[tytouf]

Oops, you are right it should have been tabs instead of tags. This feature only makes sense for inside and outside operations.

I don't know if it is easier to implement manual or automatic insertion of tabs or as part of the svg that is why I'm open to all solutions.

I think the depth and width options are mandatory for any of these solutions but the minimal and maximum distance may only be required in the case of the automated insertion.

What I read so far on the subject, confirmed by my meager experience, suggests it is better to add tabs on straight segments as they are easier to remove later on.

[tbfleming]

I don't know off hand which is easier to implement; I'm going to think about it. I had an initial idea, but it hit a nasty limitation of the jsclipper library.

[tbfleming]

I might have a jsclipper workaround for my initial idea. How about this: a user selects a bunch of path objects that represent tab areas then clicks a "Create Tabs" button. There will be an option to control how deep the cut is over tab areas. It will automatically apply the tabs to all inside and outside operations. Tab placement and length would thus be controlled by the SVG file.

My workaround might not work; if it doesn't then we'll have to try something else.

[abetusk]

@tbfleming, what is the limitation of the jsclipper library?

[tbfleming]

It does what it is designed to do exceptionally well. It gets into performance trouble when you need to perform a large number of operations against the same polygon (unmodified at each operation). It throws away its intermediate data structures then regenerates them each time. About 50% of jscut's path generation time is in code which hits this case. My initial idea for tabs would have hit it at a much larger scale.

[tytouf]

I'm not sure to understand the workflow. Does the user first select the main svg and then each pieces representing a tab or are all these paths (the main + tab areas) part of the same svg?

[tbfleming]

All operation path objects and cut path objects are part of the same svg file. Right now the user selects path objects then clicks "Create Operation". Now they'll also select different path objects then click "Create Tabs" also.

[tytouf]

Looks like it could work :-)

[tbfleming]

Failure. Clipper's open path support mangles open paths. Here are issues I ran into:

• If an open path loops back on itself (common in jscut), Clipper usually (always?) removes the redundant point. This drops a segment. I can't blindly add it back because it might cross a tab.
• It unpredictably (very hard to reproduce) changes direction on the cut up path segments. This sends the cutter shooting through area that shouldn't be cut. There's not enough information to figure out which path segments have been reversed.
• Segment order appears random. It takes a lot of work to reorder the pieces. This is error prone because the endpoints aren't always exactly equal and the random reversals introduce ambiguity.

The C++ version of Clipper normally #ifdefs out open path support. This means it's probably not well tested.

[tbfleming]

Had do do this in emscripten to get a more flexible polygon library.

Bonus feature: this works with all operations including pocket!

[tytouf]

Thanks! Only had time to try it quickly and it seems to work fine :-)

On Sat, Sep 6, 2014 at 9:30 PM, Todd Fleming notifications@github.com wrote:

Had do do this in emscripten to get a more flexible polygon library.

Bonus feature: this works with all operations including pocket!

— Reply to this email directly or view it on GitHub https://github.com/tbfleming/jscut/issues/17#issuecomment-54725643.