Wavy curves and inconsistent measurements

Hey guys,

first things first: I absolutely love Valentina! The concept is so beautiful and easy to understand and at the same time so capable of doing complex things. Keep up the good work!

Now to my issues:

  1. I made a really simple pattern for some small leather pieces I need and I noticed that my curves turned out to be a bit wavy/wobbly when exporting to a pdf or svg. While in drawing or detail mode everythings looks fine but when I switch to “layout” I can see that the lines don’t look very nice. You can see it in the screenshots.

  2. I have two pattern pieces which have the same width assigned by a formula. The formula is quite simple. It’s just a variable with a fixed value, so I’d assume the two pieces are the same width, but they are not. This also applies only for layout mode and also the exported files (SVG/PDF), but that’s where accuracy is more important than in edit mode.

The issues are minor when cutting by hand but when doing small pieces and having them cut by a plotter they would look ugly. I guess the issue with the different sizes is a mathematical rounding issue which applies because my pieces are so small. I attached the pattern so you can try it out.

Did anyone encounter the same issues? Or maybe I’m doing something wrong?

test.val (11,4 KB)

Issues I found:

  1. LF can’t seem to handle certain characters in variable names. For example, defining a formula using the line-length containing labels prefixed by ‘Ä’ causes an error, even if that is the only reference in the formula. (Created Issue #764.)
  2. Your pattern is quite small. I suspect that the curve-drawing routine is drawing straight line segments that wouldn’t show up on larger pieces.
  3. I just measured the layout with a screenshot, and the two pieces are exactly the same distance apart vertically, from the left side to the right.
  4. While you are given the option to set control points for curves manually, it is vital to your sanity to make sure that you don’t; always define their placement in the formula boxes, as shown in the image below. (Notice how I multiply the B3_B10 & B4_B13 distances by ‘0.55’ to set the distance for the vertical control points? That is to make the smoothest transition into the curve. I used ‘0.4’ for the bottom control point, as you seemed to want the bottom of the piece to be ‘pointier’.)
  5. I’m not sure why you decided to start the curve going through A7 at A and going all the way to A3, but that introduced long curves up the sides, which became even more problematic because the angles for the control points weren’t precisely vertical. (For example, the line A5_A9 was at 91.3428 degrees, not 90, which through everything that used A9 off a little. It is VERY important that you make sure that your angle and distances are absolutely precise.
  6. It is important to not have two points in the same location, as this could cause problems down the road.

If you would explain how the pieces fit together, I could help you refine your pattern.

Hmmm doesn’t seem to be a problem on my end…

Screenshot (51)

Don’t know if that’s crucial in this case… I’m assuming that these pieces are not going to be graded where it makes a difference.

Such as B4 and B2. In fact the pattern doesn’t even need those points. Less is more. I made a single multi point curve from C5 - C7 - C2. Also it’s much cleaner looking when you keep the labels close to the points and not having all the additional lines.

test.val (14.4 KB)

Screenshot (50)

1 Like

Try doing formulas in the second piece, where there are commas in the label name.

That is the second piece - there are no commas in the point names. Are you thinking of the umlauts? Interesting though… I just noticed the forums is still messing with the pics - it cropped the pic.

Screenshot (51)

Nonono. Open up the piece called ‘Schnittteil 2’, then try making the length formula of ‘Ã3„_Ä4’ equal to ‘Line_Ä_Ä1’. It won’t work.

error001

I think the rules on variables are Must start with letter or underscore ( but avoid underscores as compilers use them internally - and Valentina inserts them in creating line/spline length names )

Continue with letters numbers and undercores and NOTHING ELSE

The label names are referenced in formulae so whilst quote and dashes may look like an option, you are asking to screw up your calculations .

Also in some locales commas are used as decimal separators

1,25 * 8 may be parsed as one and a quarter times eight (1.25 x 8 ) => 10 or ( 1 , 25 * 8 ) => 200 ie 1 no now its 25 ( comma operator ) times 8

Also no matter how perfect your curves - when exported to PDF / SVG they will become slightly jagged as they are converted to polylines.

1 Like

What version and computer are you using? Seems like your keyboard is mapping incorrectly because something is changing the Ä chars to Ä on your end. There are no commas in test.val. Open up the test.val in a text editor to see. For ex:

< point angle=“270” basePoint=“23” id=“24” length=“#hoehe_schoner” lineColor=“black” mx=“0.716259” my=“0.211495” name=“Ä2” type=“endLine” typeLine=“hair”/ >

I’m looking at it in both Chrome and Notepad++, directly from the link above. That line is

<point angle="270" basePoint="23" id="24" length="#hoehe_schoner" lineColor="black" mx="0.716259" my="0.211495" name="Ä2" type="endLine" typeLine="hair"/>

Interstingly enough, when I look at it using the TYPE command at a DOS prompt to get the raw text, that line now reads

<point angle="270" basePoint="23" id="24" length="#hoehe_schoner" lineColor="black" mx="0.716259" my="0.211495" name="Ä2" type="endLine" typeLine="hair"/>

It looks like a Unicode issue. (Those aren’t commas, I found out, but a single character called a ‘Double Low-9 Quotation Mark’, whatever that is.)

I just tried the same file with 0.6a for Windows (I used 0.5 for Mac before) and it’s different there. The pieces have the same width and the curves look much smoother.

I’m going to try it with the 0.6 alpha version for Mac as well. Maybe my issues are already fixed.

@KeithFromCanada, you seem to have some issues with unicode characters for some reason. I didn’t add those weird characters. They come from an incorrect conversion of the “Ä” (A umlaut) character, which is automatically added by Valentina on the second piece.

I’ll let you know what I found out when I tried it with the alpha version on my Mac.

Never heard of this… Who knew. Lol

I just tested it on my Mac with 0.6a and it’s fixed there. See the screenshot for comparison. Both issues are fixed. Anyway, thanks for your help guys!

I’m glad it worked out for you. As for the Unicode thing, I have no idea how that came about, but it is something that needs to be fixed. Not everyone is comfortable with editing the XML of the pattern file directly to rename all of the labels.

What I don’t understand is why the Double Low-9 Quotation Mark are inserted after any A umlaut? Question is what makes your computer (settings) different than Thomas and myself - where we don’t seem to have a problem with the A umlauts?

Just to remind everyone - the layouts don’t contain any actual curves, all curves are converted to a series of straight lines (eg polylines). There’s no need to convert to polyline if you’re going to export to PDF, or Tiled PDF, or SVG, HPGL, PS, EPS, etc. So the conversion to polylines can occur during export to file formats which are intended for cutting tables, vinyl cutters, etc.

It’s possible that the initial layout creation can retain curves, and the conversion to polyline can be delayed until it’s needed, for example: during layout export to any of the multiple DXF formats which require polylines.

Unfortunately the parallel curves for seam allowances have to be polylines because you can’t generate parallel bezier curves.

Actually there is an algorithm which so very closely approximates a parallel curve that we could use it.
5cMLD
anoffsetalgorithm.pdf (723.4 KB)

2 Likes

@Thomasb, thanks for the fantastic words of support at the beginning of this thread! I’m going to add your comment to the website’s kudos scroll. Is that okay with you? :wink:

1 Like