Seam allowance visible only on the back, not on the front, when editing the pattern, same when exporting in pdf. Weird… Does someone have an explanation and or a fix? tks
I see the same behavior when generating Wahid using the Elanor measurement set on freesewing.eu. I believe it is a bug with Wahid that will need to be fixed in Wahid’s code.
Tks Benjamin. For me it worked fine up to the moment when changing some measurements. Meanwhile I will add the allowance manually.
I now think that the problem is somewhere in the FreeSewing core infrastructure, not in Wahid’s code. From testing, the actual seam path is correct, but when Path.offset() is applied to turn it into the seam allowance path, the path seems to turn into this small line at the bottom right.
Edit: added: I filed a bug for this issue:
Can you share a link that causes the issues? Everything standard with Elanor curated set and 10mm sa works fine for me.
This URL:
looks like this:
Edit: added: This seems to be a browser issue. I was using Mac Safari, but I do not see the bug using Mac Chrome browser.
Seems to work fine in Chrome and Firefox for me. Weird. Have you tried clearing the Safari browser cache? Unfortunately I don’t have a Mac for testing Safari behaviour.
The Mac Safari browser seems to be having trouble with the SVG path. Or, perhaps the SVG path didn’t get calculated properly?
In the JavaScript console:
Error: Problem parsing d=“M 244,441.19 L 243.53,436.71 C 242.33,425.35 239.33,408.42 236.31,391.5 L NaN,NaN C NaN,NaN NaN,NaN NaN,NaN L 236.31,391.5 C 233.39,375.11 230.45,358.72 229.3,347.71 C 224.71,304.08 216.28,178.2 216.15,176.2 L 205.15,167.3 C 203.68,167.45 202,167.55 200.19,167.55 C 197.52,167.55 194.58,167.35 191.65,166.81 C 187.25,166.02 182.68,164.59 179.6,161.38 C 172.06,153.51 164.29,139.9 164.29,112.45 C 164.29,88.52 168.68,69.02 173.07,54.66 C 175.39,47.07 177.71,40.85 179.44,36.09 L 173.3,23.77 L 87.23,-7.55 L 74.42,-1.58 C 73.57,0.75 72.81,3.61 72.07,6.98 C 66.44,32.69 60.84,94.13 -15.49,173.05 L -18.3,180 L -18.3,427.01 L -15.37,434.08 L 39.62,489.06 L 50.69,491.16 C 52.28,490.47 66.96,483.63 96.79,476.77 C 100.34,475.96 104.1,475.14 108.07,474.33 L 132.87,472.87 C 133.45,472.68 134.03,472.5 134.62,472.32 C 160.02,464.43 193.66,456.53 235.1,452.18 z”
Am using Chrome under Windows. Initially had no issue and allowance was appearing ok. Issue appeared after I changed some measurements and did the update.
Maybe it’s just because Safari has a slightly different precision with Javascript calculations…
There’s several NaN in the path.
That’s not a browser bug, but something we need to look into.
(NaN = Not a Number)
I have found an example that breaks for me. Looking into it. The output of the reduce function looks plausible to me at first glance, but I’m checking if that change could have unintended consequences.
Perhaps Path.__pathOffset() or Path.__asPath() could check to see if any values are NaN and simply skip that section or return false if so? (I’m assuing it’s some sort of bug in Bezier.js).
I’m testing something like that at the moment to find the cause of the NaNs
If anyone is interested, this testcase fails and creates a path with lots of NaNs:
it('Should offset a curve2', () => {
const curve = new Path()
.move(new Point(233.58820676923352, 437.7581608165166))
.curve(
new Point(231.23631634571132, 415.3814181707305),
new Point(221.70910430613077, 371.13489592600627),
new Point(219.35721388260856, 348.75815328022014)
)
const offset = curve.offset(10)
expect(offset.length()).to.be.greaterThan(0)
})
The NaNs are created because the new reduce function outputs a null length path:
This is hopefully trivial to fix.
Created a patch: #287 - Fix a special case in the reduce function when pass1 created very short segments - freesewing/freesewing - Codeberg.org
Tks to you all for the quick fix. 