Hey Michael,

We're actually looking into switching to git. Perhaps Krzysztof can chime in and let us know what the status of things is. Honestly, it makes more sense if you spend more time working on actual code rather than learning a vcs that we're looking to move away from.

Cheers, Josh

On Mon, Feb 29, 2016 at 10:00 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:

Dear Josh,

...

Yes, I personally think this would make sense to add directly into Inkscape.

very well. I think quite a few people would love to see this in Inkscape.

...

Do you have your code hosted anywhere online for other to take a look at and/or test?

not yet. The main purpose of my email was to discuss the best method to do this. I guess if you plan to integrate it, I should create an embroidery branch on launchpad, which means I would need permission to do so. I should say that I have close to 0 experience with bzr, but quite a bit with git and before with SVN, Clearcase & Co.

If you first want to check if I do reasonable quality code, I can of cause upload a patch e.g. on my website.

In case you want me to start on launchpad right away: my launchpad account name is MSoegtrop.

Best regards,

Michael

On 29.02.2016 04:41, Josh Andler wrote:

...

Hey Michael,

Yes, I personally think this would make sense to add directly into Inkscape. We already have Gcodetools extensions in trunk (which is

"special

...

case" like embroidery), so to me it seems like it would be a great fit to extend the functionality of Inkscape to include this.

Do you have your code hosted anywhere online for other to take a look at and/or test?

Cheers, Josh

On Sat, Feb 27, 2016 at 6:39 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:

...

Dear Inkscape Developers,

I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.

Below is a list of the additions I did / I am working on.

Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).

Best regards,

Michael

1.) Ways to fill an area with clusters of contours

Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.

2.) A way to connect sub path of a path into one continuous path

I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.

3.) A way to cut a path into stitches (straight line segments) in a controlled way.

I added an LPE to do this, but it is quite primitive as yet.

4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.

I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.

5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.

I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.

6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.

Currently I do this semi-manually. Doing this automatically might be quite complicated.

---

...

...

Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Dear Inkscape Developer-Team,

I just wanted to give an update on the embroidery functionality. Essentially it works, but there is one open end.

The open end is a function to reorder the cut pieces such that a minimal number of longer jumps is needed in between (jumps are expensive in embroidery because the thread needs to be cut and knot). This is essentially a traveling salesman problem with a few additional complexities.

1.) I don't connect points as in a usual TSP, but lines, and the tour needs to visit each line exactly once. This is similar to a usual TSP where pairs of cities have a 0 distance connection, but the difference is that I need a guarantee that the 0 distance paths are all taken. When I use a usual TSP algorithm, this is likely but not guaranteed.

2.) For performance reasons I collect groups of lines where both end points have a mutual nearest neighbor (think of a zig-zag pattern). This is a very common situation in embroidery patterns and cuts down the number of segments by more than a factor of 10, which is a substantial saving for a TSP algorithm. These zig-zag blocks results in block with 4 end points and 2 choices of 2 points. So I don't connect just lines, but this kind of blocks with 2 choices of endpoints.

3.) Since I usually want an open path, I can ignore the longest connection.

Points 1 and 2 work with something like a variable k "Lin" algorithm. Maybe later I will implement a Lin-Kernighan algorithm, if the Lin algorithm is too slow, but with k=3 it is quite fast (fraction of a second) even for quite complex patterns (29 zig zag blocks) and gives good results.

What I am struggling with is point 3, which is essential to get good results (or at least I believe so). I thought this would be easy, but it is either slow or results in complex book keeping.

Best regards,

Michael

On 05/20/2016 04:14 PM, Alexander Brock wrote:

I made a lib2geom toy which creates stitches especially for hair-like effects where an area should be filled with lines similar to a given curve:

http://i.imgur.com/bx829Uk.png

Code is in the src/toys/hair* files:

https://github.com/abrock/lib2geom

It works the following way:

1. Create offset curves until there is no intersection between curve and

offset curve. 2. Create equidistant stitches on the middle curve 3. Create stitches similar to the ones on the middle curve on all other curves 4. Calculate intersections between curves and area outline. Throw away stitches outside the area. 5. Find the best ordering of lines so the amount of stitches along the area outline for connecting different parts is minimized. I do the connecting stitches along the outline since I sometimes want to use a very low density of lines and then I can't hide the connecting stitches under "future lines".

Update: I made an executable called "hair" which takes two filenames as command line arguments ($outline.svgd and $path.svgd). The contents are read by read_svgd, I usually just copy the content from a SVG file.

The stitches are computed and the result is written in $outline.svgd.svg / $outline.svgd.txt. The .txt file can be converted to many different embroidery formats by libembroider-convert:

https://github.com/Embroidermodder/Embroidermodder

I applied the method to mane and tail of this vector:

http://imageconstructor.deviantart.com/art/Luna-545158121

Here you can see the results (input paths and embroidered versions): http://imgur.com/a/bRrko http://imgur.com/a/LVs8j http://imgur.com/a/d0sc1

I tried to make the stitches follow the direction of the hairs.

One problem is that Inkscape::half_outline sometimes increases the number of nodes which leads to exponential node count increase when applied repeatedly:

http://imgur.com/a/doJaU

Is there an alternative? If not I might have to write one.

Best Regards, Alexander

On 11/13/2016 07:11 PM, Jabiertxo Arraiza Cenoz wrote:

Great work Alexander!

Thank you :-)

Maybe you can use the half_outline form join_type LPE intead the livarot one.

I searched for it but I only found the version I'm already using. I had a closer look at it and implemented some functions which don't subdivide paths if the error of the offset curve is too high but adjust the lengthes of the node handles.

This commit shows the new functions (...._stable): https://github.com/abrock/lib2geom/commit/f13af53ebf0076deb5b48acf7914db1714...

It doesn't work perfectly, I'll continue to improve it.

Best Regards Alexander

On 11/21/2016 05:53 PM, Jabier Arraiza wrote:

Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.

I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstroke.cpp

The old method for offset_cubic: 1. move the control points 2. checked if the error at t=.5 was below some threshold 2. a) if yes return 2. b) otherwise subdivide path and repeat (up to some recursion depth limit).

The new method: 1. move the control points 2. Find the point on the curve where the distance differs the most from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).

This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.

Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.

Best Regards, Alexander

Hi Alexander,

We've not moved to github yet, so if you need to do a merge request, you'll either have to make a bzr branch or get the help of another developer (hopefully on the mailing list) to do the merge for you.

Best Regards, Martin Owens

On Tue, 2016-11-22 at 01:30 +0100, Alexander Brock wrote:

On 11/21/2016 05:53 PM, Jabier Arraiza wrote:

...

Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.

I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstro ke.cpp

The old method for offset_cubic:

1. move the control points
2. checked if the error at t=.5 was below some threshold
3. a) if yes return
4. b) otherwise subdivide path and repeat (up to some recursion depth

limit).

The new method:

1. move the control points
2. Find the point on the curve where the distance differs the most

from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).

This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.

Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.

Best Regards, Alexander

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 11/22/2016 10:41 AM, Jabier Arraiza wrote:

I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.

I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe

So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd

I start using your code in my offset branch now to start trying.

I'm glad to hear that :-)

Best Regards, Alexander

I think this beabiour is a bug and your proposal is ok.

Cheers, Jabier.

On Tue, 2016-11-22 at 13:01 +0100, Alexander Brock wrote:

On 11/22/2016 10:41 AM, Jabier Arraiza wrote:

...

I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.

I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe

So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd

...

I start using your code in my offset branch now to start trying.

I'm glad to hear that :-)

Best Regards, Alexander

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Hi Alexander and all.

I just sent you as reviewer of the offset LPE I just resubmit. I want it soon merged for try to remove SP-Offset on 0.93. Finaly I can get similar performace, than SPLivarot offset, + allow another line joins on expand offset than the previous rounded only.

I use your 2geom-pathstroke code. We can rollback it to previous one before merge, or, if the Extrapolated Cases are covered, i could commit  it, and when 2Geom get it and sync with inkscape we can remove this files from helper folder.

Also another question. There is a LPE called Interpolate Paths that maybe can be improved with your code en embrodery.

Cheers, Jabier.

On Tue, 2016-11-22 at 10:41 +0100, Jabier Arraiza wrote:

Hi Alexander,

I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.

I start using your code in my offset branch now to start trying.

Cheers, Jabier.

On Tue, 2016-11-22 at 04:06 -0500, Martin Owens wrote:

...

Hi Alexander,

We've not moved to github yet, so if you need to do a merge request, you'll either have to make a bzr branch or get the help of another developer (hopefully on the mailing list) to do the merge for you.

Best Regards, Martin Owens

On Tue, 2016-11-22 at 01:30 +0100, Alexander Brock wrote:

...

On 11/21/2016 05:53 PM, Jabier Arraiza wrote:

...

Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.

I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-path st ro ke.cpp

The old method for offset_cubic:

1. move the control points
2. checked if the error at t=.5 was below some threshold
3. a) if yes return
4. b) otherwise subdivide path and repeat (up to some recursion

depth limit).

The new method:

1. move the control points
2. Find the point on the curve where the distance differs the

most from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).

This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.

Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.

Best Regards, Alexander

---

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Yes his place is in 2Geom but currently this file is inside helper folder in inkscape. I try remember Krzysztof say to Liam P. White that maybe we need to move it in the future.

Currently the original of this file is used on the Join Type LPE.

Cheers, Jabier.

On Tue, 2016-11-22 at 10:51 +0100, Marc Jeanmougin wrote:

Hi,

Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )

I can't wait to see inescape in GutHub. I believe it'll bring more visibility and contributions to the project.

Em terça-feira, 22 de novembro de 2016, Martin Owens <doctormo@...972.....> escreveu:

On Tue, 2016-11-22 at 10:51 +0100, Marc Jeanmougin wrote:

...

Hi,

Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )

True, and if re-factored into that it makes sense to keep it there.

Do we plan to keep lib2geom there if Inkscape moves to GitLab instead of GitHub? No need to keep them in the same place of course.

Martin,

Hi Alexander. Your code works very well in my offset branch, Thanks.

One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.

To me the first option is the first one.

Cheers, Jabier.

On Tue, 2016-11-22 at 23:28 +0100, Alexander Brock wrote:

On 11/22/2016 11:21 AM, Martin Owens wrote:

...

...

Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )

True, and if re-factored into that it makes sense to keep it there.

I could:

1. Move the file to lib2geom and create a pull request there
2. Make Inkscape trunk compatible to the new version of lib2geom

Thoughts?

Best Regards, Alexander

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Great!

On Wed, 2016-11-23 at 16:03 +0100, Alexander Brock wrote:

On 11/23/2016 01:22 AM, Jabier Arraiza wrote:

...

Hi Alexander. Your code works very well in my offset branch, Thanks.

One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.

I copied my code into inkscape trunk (on my machine) and tested it using the "Join type" LPE. I noticed two problems:

1. It is rather slow
2. Some degenerated cases are not handled well (glitches).

I'm working on it and I'm going to make a merge request to inkscape which replaces the function offset_cubic.

Best Regards, Alexander

---

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Cool. Im out home, try it on weekend.

El 2016-11-23 22:42, Alexander Brock escribió:

Hi,

I made the offset_cubic function more stable and fast and merged it into the latest version from Inkscape trunk so you can test extrapolated joins etc., you can find it here so you can test it if you want:

https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstroke.cpp

I played a little with the Join Type LPE and collect path data samples so I can automatically compare different offset methods:

https://github.com/abrock/lib2geom/tree/master/src/tests/half-outline-paths

Feel free to send me any path data / svg file with paths that behave odd.

I added a svg file with comparisons between the new and old behaviour and proposal for "correct" behaviour which I might be able to implement.

Best Regards, Alexander