I've noticed a vague printing issue, that I haven't spent much time trying to replicate, but seems to be persistent.  I'm thinking it has to do with using a pattern piece that is too small to be labelled.  E.g. yesterday my pattern included a narrow binding strip.  I've noticed before that on the layout screen, some pattern pieces have a large invisible buffer such that they can't be placed near an edge.  This pattern piece was an example, I couldn't place it anywhere near the bottom edge of the layout but I was able to place it near the top edge.  When I did this and generated a pdf, the pages where misaligned--the cut marks did not correspond with the edges of the page image, and the pdf was unusable.  This happened twice, but when I removed the binding strip, the pdf was back to normal. (I don't know if this helps, but job ID 14809 is an example.  The svg file looks fine, but the pdf is misaligned. 

Thank you for the detailed post, we shall see to these issues. I have noticed that in the online preview it is often the pieces created with along function that may cause the buffer effect, especially when one previews the whole printing area in small scale. This is due to some rounding up issues in the library, the 'infinite' length of a curve that is rather a line etc etc. We are fixing it case by case, but there seems to be something left.

When seam allowances are added to the patterns, is that essentially calling the 'along' function?  I did use 'along' directly in this pattern to estimate the length of the collar band, but I didn't actually included that line in a pattern.

Yes, that would be along function.

Fingers crossed, that would be great.  I can appreciate that deciding how to extend and clip a complicated corner is difficult.  But I really don't understand how this sometimes leads to divots on the wrong side of the seam line.  Looking forward to an update.

I'm thinking the new 'packing' is underway.  It produces an initial layout, but when I change the paper size, something different is going on.  All the pattern pieces are spread out horizontally and I needed to expand to 28 pages wide before I could find the pieces and drag them into a reasonable configuration.  This is slow and prone to timing out. 

The first bug was fixed in the morning, we have made a release already. The packing for different paper size will be fixed as well.

Those are all good things. Saving paper preference will be a big help.  Thanks.

I've seen it.  It's already training me to always press save before hitting the print button :) Hopefully it isn't too annoying.  I have definitely lost changes by having the print screen hang or accidentally leaving from that screen, so it's a good warning.  Thanks.

Has there been any thought to including pattern elements that don't appear on both sides of a garment?  E.g. a breast pocket placement or a say a binding notch that is offset from the center line.  I would find that useful.

Well, frankly speaking, I never thought of it, as I never had a case of a single notch, and as for the pocket placements I usually include it all the same and mention in the instructions which one should be used (or both, you know).

Yes, for a pocket it's not usually a big deal.  Especially if there's a center placket, I wouldn't cut two fronts just to have one that tells me to place a pocket, and one that tells me not to.  And, if the pattern is cut on the fold, it's all moot, all the markings should be there, and it has to be sorted out with instructions.  But, if nothing else, this would allow looking at the full size pattern with everything in place as a reality check.  And for the occasion where there is a tiny asymmetry, like a zipper placket on the left side, it would be nice to have the option of printing a full size pattern that doesn't have extra notches.  Anyway, just something I'd put to use.

In fact, with folded and flipped patterns it is best to describe the trace so that the flip/fold line is the last segment of it. So you begin at the first actually existing element, go clockwise and end the trace at the point where the fold/flip line would start. In this case it should be ok re seam allowances.

That doesn't fix the problem for the pattern I was working with.  The trace is clockwise, and the first element is a neckline.  If I add the first point of the neckline as the last point of the trace, nothing changes.  If I add the fold line as the last element of the trace nothing changes.  If I replace the neckline with a line [neck.p1:neck,p2], it works.  If I replace the neckline with a new arc, neck_new = arc(neck.p1, neck.p2, neck.a1, neck.a2), it works.  All I can figure is the particulars of the neckline are causing an error at the initial point of the path.  Similar to sort of blips that might occur at any other intersection of the path, in particular maybe the sort of blip, that throws a point of the seam allowance inside the contour of the path.  Anyway, just a guess.  Maybe there's nothing *better* about the new arc, but it just happens to work with 'along' while the first one didn't.  I've scratched my head over this behavior before, I just didn't spend any time trying to figure out if I was causing it. 

The correct path should end at p4 - trace(c2,p2,p3,p4), - but I can see it still doesn't work. I have forwarded this to the IT and they are working on it as we speak :)

Thanks for clarifying.  Yes, normally I stop the trace at the second end of the fold line, I wasn't sure if you were saying that closing the loop by including the fold line would have an effect.  Anyway, I've definitely run into strange behavior using flip and fold.

Could you please try that script again?

Excellent, the toy example is working now, and also the shirt where it was causing a problem, no longer needs a work around.  Maybe it's my imagination, but it also looks like the seam allowances on something I was working on yesterday have improved.  There were some points where a side seam and waist met at a convex angle that where the seam allowance would have a big bite missing and now they look good.  But, maybe that was a change on my end.

OK, so I'm certain I saw it work improve, but now it's back to the previous behavior.

There was indeed a problem with that release, so we rolled it back and released anew yesterday. Could you check again please?

Yes, it's now working again.

Thanks for the update, I will see if this can be easily fixed... but in my opinion this is rather a thing that we will be fixing when finishing the different options of drawing seam allowances (as in specific variants when drawing seam allowances for hem, around darts, etc)

Oh, exciting, I'd much rather see refined options for seam allowances.  I don't think the current situation could cause confusion, and it only occurs if the fold line isn't perpendicular to the pattern lines, which is rare except for things like a v-neck.

I'm having an issue with the function mark() and type 'mark_circle'.  Circle markings are drawn correctly in the editor, but in the real size print out, the marks don't stay in position.  This seems to be related to all the flipping and rotating that the packing algorithm does.  At some point the circle doesn't reflect/rotate with the pattern.  If I instead use 'mark_square', everything works as expected.