Yes, this is easy to do, it will become available with the next release - maybe I will even ask to have this released today 

So basically this is relevant for flip only, and for inc() that are to be printed on just one side. As in inc() for all of them, and incleft() incright() for the sides?

Frankly, I would probably use the half pattern, and simply include everything on it. As in inc(left_pocket) - even if it's the right half. I don't think drawing the pattern twice is useful if there's just a minor difference like pocket placement, as saving on paper is always a priority. I would inc the pocket outline on the right half, then type ("LEFT SIDE ONLY",pocket_trace.p1,90) and stop there. :) If there should be no edge, you can still flip the pattern, and the incs with the pocket trace and the LEFT ONLY text will be present on both sides.

Yes, I think that's for the best, and it's what I mostly do.  Just talking about technical drawings got me thinking again, because that's a time when producing the mirrored image is essential, yet there are often tiny asymmetries, like a seam top stitched to the left. (But, I think I can do that by creating two halves and mirroring)  I'm sure I'm in the minority, but even in patterns, I prefer full size pieces, I don't often cut on the fold, and if there's a notch that has to be on one side only, I'm bad about making mistakes.  So I like to keep track of at least a view of the full size pattern, and the folded version.  As far as printing, I do appreciate fewer sheets, and I'm satisfied to print half patterns and even overlap patterns, and then if necessary using tracing for actual patterns, so I really like that I can do that dynamically with sewist.  Traced patterns are also easier to store than full glued together pdfs.  Thanks for checking!

For the technical drawing I have a trick for you. 

Makes sense, thanks!

With the pattern function, the line name() can take a string which is a variable, and also concatenate multiple strings.  Which is sometimes useful. E.g., I've added a calculated cup size to the pattern name.  The line fabric() can only take a literal string.  Does it need to be this way?  I have a pattern which includes trim strips which might be cut from the garment fabric or from binding like fold over elastic.  I'd like to use the same template for either situation, and indicate the fabric type correctly.  I could put the entire pattern under an if() statement and handle things that way, but just setting up a string would be simpler.

Hello,

Playing with generating image files, I notice there are still issues with paths losing attributes when a pattern is moved.  E.g. I have a shirt hem marked with a dash, it's a curved path, not a line.  I want to draw the front over the back.  But when I did this by using mirror on the completed front pattern, the hem reverts to a solid line.  If I draw the pattern in position, it's fine.  This is really a problem with mirroring a pattern, not the image generation.

Hello and thank you for your message,

Sure, ID 1345 produces the issues I was noticing.  Line 213 contains a mark_apex, M_PB.  The center cross is plotted correctly, the circle ends up off the pattern.

I'll post a ticket for the circle mark.

I wrote a simplified version, ID 2531.  The issue is just with transforming patterns that include an arc.  If the arc is dashed and included in a pattern, then mirroring or moving the pattern, the arc becomes solid.  Those are the two transformations I checked.  It doesn't happen with lines or curves, or if the arc is part of larger path.  Those are the included objects I checked.  I use a lot of arcs, but I guess I don't manipulate completed patterns often, so I hadn't noticed this until using the image generation.

Fixed :)

Put to use, thanks!

Could you please check?

Yes, that fixes the markings on arcs, thanks!  The drawing is now what I expected to see:

I have noticed there's a strange behavior with the pattern function, I think it's unintended.  If I name a pattern p1 = pattern() and then I draw a second pattern but give it the same name, I end up with the two pieces grafted together.  However, there will be some sort of nesting in the cutting layout and other strange behavior, so I assume this is a bug.  If the pattern name is reused, I'd expect it to replace the previous pattern.

I really don't, maybe I'd open a template with an existing sleeve with the intention of replacing only that pattern piece but keeping the name.  It's really just an easy mistake to make (copy and paste and forget to rename), and I found it more confusing when I first noticed it, than say having the first pattern over written.  I think it's the only object that has to be explicitly deleted.  Redrawing a path doesn't cause the previous drawing to disappear, but if it's included in a pattern or transformed, only the most recent instance is used.  Once I did realize the patterns were summed, I couldn't find a way to put it to use, because then everything like the spec sheet, or the cutting instructions list the summed pattern multiple times.  E.g. this pattern is supposed to have a left and right front, maybe since they're small, I'd like them to print as a unit.  But if I give them both the same name I get two copies of the combined pattern on the cutting layout and the spec sheet over calculates the fabric usage: 

Thanks for the detailed info, I shall talk to the IT about it, and see where else this might be used.

Makes sense I'm sure there's some reason, thanks for checking.  I'm used to it, I just wasn't sure if it was intended. I might do it intentionally, if it didn't upset the spec sheet and instructions, but I don't need to make things more complicated.

I find the instructions for the 'spread' function difficult.  I'm not sure if something is not entirely as described or if I'm just misreading, but I think the text could be clearer.  I understand the first list contains two special paths 'upper' and 'lower' which will be transformed.  The path upper will be bent but the length is maintained, while the length of 'lower' will be stretched.  All the other objects are rigidly transformed.  There are places in the text where 'upper' and 'lower are instead referred to as 'inner' and 'outer', it would be simpler if the same names were used everywhere, including diagrams.  The manual instructions say:

I believe this is a bug that accumulated silently over a few releases and I will have the IT look into it.

Thanks.  It's not a function I use that often, and it's complicated, so I have to look it up every time.  Maybe it is a new problem.  I think what's happened to me is sometimes my first choice of listing works, but other times I'd get unexpected behavior and I'd just give up.