August 2017 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Fwd: SVG in 92 and Phyisical Scale
by Lex Neva 25 Aug '17

25 Aug '17

Hi James, I can't solve your direct problem, but I can offer an alternative, inkscape-silhouette: https://github.com/fablabnbg/inkscape-silhouette It's an inkscape extension that can directly control a silhouette cutter without the need to use Silhouette's proprietary software. Unless I'm mistaken as to your intent, I think this will allow you to not only master in SVG, but in fact work _only_ in SVG. As a bonus, inkscape-silhouette gives me much more control than the free version of Silhouette Studio. Wow, your paper toys are amazing! I've been doing stuff in a similar (though far less polished) vein using my Portrait to cut polygons that my children can fit together into polyhedra. Check out this PR and my fork for ideas: https://github.com/fablabnbg/inkscape-silhouette/pull/45 Hope that helps, Lex > ---------- Forwarded message ---------- > From: "James Fritzler" <jimbox13@...3425... <mailto:jimbox13@...3425...>> > Date: Aug 23, 2017 10:11 > Subject: [Inkscape-devel] SVG in 92 and Phyisical Scale > To: "Inkscape-Devel" <inkscape-devel(a)lists.sourceforge.net > <mailto:inkscape-devel@lists.sourceforge.net>> > Cc: > > Hi Inkscape Devs! > > > I’ve used Inkscape for about five years now and have built up > quite the library of svg files and have been using 91 since its > release.My main creative effort is to build paper toys that I > print and cut (in bulk) on a Silhouette Portrait cutting > machine.(More info on my works at http://netroids.net > <http://netroids.net> ).I have a 100s of files and hoped to use > them as my long term "masters” given that SVG is not proprietary > and has had such great page layout fidelity for me. > > > I’d love to update to v92 and future versions but, as is commonly > known, the svg save logic has changed to support a new CSS > standard of 96dpi and it is affecting my ability to import into my > cutting software. > > > It seems that perhaps the values written by Inkscape in 91 svg > files are encoded using a 90dpi scale from their original > design-time dimensions. In the past I’ve had much success > importing SVGs from Inkscape 91 into Silhouette studio for > years.(Granted, I do perform a little cleansing in a copy of the > master svg before I go to Silhouette: I simplify the layers, > ungroup, and flatten out clones into their own objects. Perhaps it > is just serendipity that the Silhouette Studio imports SVGs at the > 90dpi.(I tried asking them about dpi but I couldn’t "break > through" their first-tier help desk support "fire wall".) > > > I know there’s an import prompt and process for opening 91 files > in 92 and I have participated in the launchpad forum and chat with > Mc about this topic.(my user name is jimbox13). > > > Unfortunate for me, none of the prompts give a workable > solution.Here’s what happens to my files based on each option.(I > used a diff tool in to investigate some of the changes.) > > * "Accuracy for sizes and position of paths" (Desired option) > o Grid and guides appear to be changed – though I’m not sure > to what extent. > o Rectangles, paths and strokes are sized up by 6.667% > o Inkscape Designer Outcome:shapes and sizes correct right > based on the page. :) (bug #1712114 occurs.) > o Cutter Software Outcome: File is too large (by 6.667%) for > cutting area.:( > * "Digital Art" > o Grid and guides changed to some degree. > o Rectangles and paths not changed. > o Inkscape Designer Outcome:shapes and sizes are too small > for the page :( > o Cutter Software Outcome: shapes and sizes are correct :) > * "Accuracy for masks and clips" > o Grid and guides changed to some degree. > o Rectangles, paths and strokes are changed to some degree, > not the same as above. > o Inkscape Designer Outcome:shapes and sizes correct right > based on the page. :) (bug #1712114 does not occur.) > o Cutter Software Outcome: File is significantly too small > for cutting area.:( > > None of these options produce a svg that maintains its correct > physical dimensions across both software packages.I tried > experimenting by customizing the "units.xml" file in 92 without > success. > > > Here is my original v91 file zipped.(I added a background > rectangle that is the size of the page to help troubleshooting.) > > https://www.dropbox.com/s/q6o17j5an2piiw3/acutra_TOCUTv91wBG.zip?dl=0 > <https://www.dropbox.com/s/q6o17j5an2piiw3/acutra_TOCUTv91wBG.zip?dl=0> > > > Is there anything that can be done? > > Thanks > > Jim > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > <https://lists.sourceforge.net/lists/listinfo/inkscape-devel> >

1 0

Re: [Inkscape-devel] Embroidery extension
by Lex Neva 25 Aug '17

25 Aug '17

Hi Michael, Sorry for the delay! I didn't even know there was an embroidery LPE. I don't see it in 0.92.1... how can I test it out? The extension that Susan was referring to is here: https://github.com/lexelby/inkscape-embroidery It started off as a little project by jonh, and then it migrated to github, and then I forked it and hacked the heck out of it. I've rewritten most of the major sections at this point. For exporting, I'd recommend you examine embroidermodder2. That project seems to be mostly abandoned at this point, but it does have a nice little library that understands all major (and many minor) embroidery machine file formats. You may even be able to get it to convert directly from an SVG to a .PES file, for example. I included some details on this in my README. The math problem I'm having has to do with fill stitching. The general problem is: how do I fill a generic shape with rows of stitches? The specific parameters are: 1) Stitch back and forth (like mowing a lawn). 2) Don't cut the thread. 3) Don't sew over the same section twice. 4) Don't do running stitch over the top of areas you've already done rows of stiches on. 5) Line all the stitches up to make a visually pleasing pattern. I have an implementation already, described here: https://github.com/lexelby/inkscape-embroidery#autofill This works pretty well. Give it a region and it will break it up into sections (each of which by itself can be filled all in one go). To get between sections, it runs around the outline of the shape. The idea here is that usually, one will do satin stitch around the outside of a fill region, covering up the running stitches. As described in the README, the problem is when you give it a region with holes in it. Things get very complicated, and I have yet to come up with an algorithm that a) can reliably fill all regions without getting "stuck" with nowhere to go, and b) doesn't take forever to run. Right now, my hacky workaround is to convert a region with holes into one without holes by cutting a very small rectangular section out of the shape (see the README). This works, but it's not ideal and it requires a lot of extra effort on the part of the user. The ideal solution would somehow figure out an ordering for embroidering the sections, such that every section gets filled in but none of the rules above are violated. Bonus points if it can avoid running around the outside of the shape to get between sections. It would instead run through the middle of regions of the shape that have not yet been filled in, so that the running stitch gets hidden by the rows of stitches that are filled in later. The biggest problems I have yet to wrap my head around are: 1) How to avoid getting into recursive/NP-complete hell. Taking more than 10-20 seconds would really be a bad user experience; 2-3 seconds max is really what I'm aiming for. 2) How to figure out how to get from point A to point B inside a closed polygon, running over only sections that haven't been filled in yet. 2 is especially hard for me, and I think it's the kind of thing that inkscape devs probably already know how to do! I really don't understand how I can do pathfinding in an arbitrarily complex shape like that without writing thousands of lines of code. I know this kind of algorithm is possible. Commercial embroidery design software makes this look easy. I want to bring that to the open source world. I haven't been able to find any discussion of this kind of algorithm with repeated and creative googling. The closest I can think of is lawn-mowing algorithms, about which I found one paper that is unfortunately a bit beyond my level of math understanding. Some examples of what I've made so far: https://github.com/lexelby/inkscape-embroidery/tree/master/images/patches This one is an especially good example of a complex fill-region with a hole: https://github.com/lexelby/inkscape-embroidery/blob/master/images/patches/c… The black circular section in the center contains a hole in the shape of the white spade, because you can't do one color of fill-stitching on top of another. To make this, I manually broke the shape up into sections and tinkered with ordering until it worked out. Anyway, thanks for listening, and any help would be appreciated! --Lex On July 30, 2017 6:47:31 AM Michael Soegtrop <MSoegtrop@...3339...> wrote: > Hi Lex, > > I did the embroidery stitching LPE and the path cutter LPE, both are > very useful for embroidery design. What is the embroidery extension > Susan mentioned below? Hope we didn't do the same thing. > > Any discussions on the topic are welcome. What is the math issue? > > My next plan is to write an export filter in some documented and common > import format for stitching machines. Suggestions on the format are welcome. > > Best regards, > > Michael > > On 28.07.2017 20:20, Susan Spencer wrote: >> Hi Lex, >> This is the dev list for Inkscape. There's a wide range in backgrounds >> for devs here, and new contributors are welcome. >> >> Hi devs, >> Meet Lex Neva, he's a fantastic programmer and has been contributing to >> the embroidery extension. He's done some mind blowing work with pattern >> fill. He's looking at a particular issue and has some questions for the >> math heads amongst you. >> >> Good luck with 0.92.2 release! >> >> Best, >> >> Susan Spencer >> http://valentina-project.org <http://valentina-project.org/> >

4 4

Re: [Inkscape-devel] Embroidery extension
by Lex Neva 25 Aug '17

25 Aug '17

Hi! Sorry for going dark there -- everyday life intrudes fairly often. Neato, and thanks for the explanation! It does indeed look like your stuff follows a similar method to inkscape-embroidery. A few minor differences: * The extension handles creating a "grating" of lines automatically and intersects them with the fill region using Shapely (a Python extension). * The fill pattern is handled automatically through the insertion of extra nodes as you mentioned. Currently there's only one pattern: a sort of stair-step/staggered pattern that is visually pleasing. I cribbed it off of a pattern I bought online that was made using a commercial embroidery design program. I'd love to understand how to code more complex patterns, but I haven't given much thought to it yet. * The extension used to have a TSP solver of its own, but it really didn't do a particularly good job. I started off trying to fix bugs and ultimately just ripped it out. Instead, I carefully order paths in Inkscape. The new Objects panel is key for this, and it's a hugely awesome addition to Inkscape! The only part I struggle with is that Inkscape doesn't want to let you reorder objects relative to each other if they don't intersect (or nearly intersect). Ultimately, the problem I brought up for discussion boils down to the same problem you're solving with the your TSP algorithm. *Question: *what does your code do if it needs to get from one section to another that is distant? Does it just jump-stitch? Here's a brief description of how to use EmbroiderModder2's libembroidery to convert between formats: https://github.com/lexelby/inkscape-embroidery#optional-conversion-program I'd suggest that your code simply output a CSV in the format libembroidery understands, and then you can make use of its knowledge of pretty much every manufacturer format to convert it to a format compatible with your machine. --Lex On 7/30/2017 11:47 AM, Michael Soegtrop wrote: > Dear Lex, > > I guess we are trying to solve the same problem, but differently. I > wanted to have more control than semi automated fillers provide, so I > added 3 LPEs, which are in Inkscape 0.92.2: > > 1.) A bool LPE to do intersections / unions, ... of areas, so that one > can construct the areas to stitch from drawing areas. > > 2.) A path / path group trimmer LPE, which restricts a set of paths to > an area (or oustide of an area. There are already two path interpolation > LPEs which allow to create sets of paths with fine control over local > direction and density. > > 3.) An LPE to convert a set of paths into stitches. This includes an > almost reasonable traveling salesman problem (TSP) variant solver for > ordering groups of stitches to minimize the traveling in between. It can > still be improved. It is a bit more complicated than standard TSP > solvers, because it looks into groups of parallel stitches which have 4 > possible ends. > > > My approach is as follows > > 1.) Make a drawing > > 2.) Use the bool op LPE to create (in a new layer) the areas to fill > with each color / stitch style. > > 3.) Create a set of path to control density and direction using path > interpolation LPEs. This allows a great deal of control, e.g. for hair. > I don't think any commercial tool allows this amount of control. > > 4.) Use the path trim/cut LPE to trim the paths created in 3.) to the > areas created in 2.) > > 5.) Use the embroidery stitch LPE to convert the paths to stitches. > > Sometimes I use the cut / trim filter also to create intermediate nodes > in paths to create special stitching patterns. These nodes are not > visible in normal drawing, but after stitching they are visible. > > Of cause for simple cases, it would help to extend it with a more > automated approach, which is what you appear to be working at. > > I am very interested in the import/export library you mentioned. > > It would be great to work together on this. > > Best regards, > > Michael >

1 0

SVG in 92 and Phyisical Scale
by James Fritzler 25 Aug '17

25 Aug '17

Hi Inkscape Devs! I’ve used Inkscape for about five years now and have built up quite the library of svg files and have been using 91 since its release. My main creative effort is to build paper toys that I print and cut (in bulk) on a Silhouette Portrait cutting machine. (More info on my works at http://netroids.net ). I have a 100s of files and hoped to use them as my long term "masters” given that SVG is not proprietary and has had such great page layout fidelity for me. I’d love to update to v92 and future versions but, as is commonly known, the svg save logic has changed to support a new CSS standard of 96dpi and it is affecting my ability to import into my cutting software. It seems that perhaps the values written by Inkscape in 91 svg files are encoded using a 90dpi scale from their original design-time dimensions. In the past I’ve had much success importing SVGs from Inkscape 91 into Silhouette studio for years. (Granted, I do perform a little cleansing in a copy of the master svg before I go to Silhouette: I simplify the layers, ungroup, and flatten out clones into their own objects. Perhaps it is just serendipity that the Silhouette Studio imports SVGs at the 90dpi. (I tried asking them about dpi but I couldn’t "break through" their first-tier help desk support "fire wall".) I know there’s an import prompt and process for opening 91 files in 92 and I have participated in the launchpad forum and chat with Mc about this topic. (my user name is jimbox13). Unfortunate for me, none of the prompts give a workable solution. Here’s what happens to my files based on each option. (I used a diff tool in to investigate some of the changes.) * "Accuracy for sizes and position of paths" (Desired option) * Grid and guides appear to be changed – though I’m not sure to what extent. * Rectangles, paths and strokes are sized up by 6.667% * Inkscape Designer Outcome: shapes and sizes correct right based on the page. :) (bug #1712114 occurs.) * Cutter Software Outcome: File is too large (by 6.667%) for cutting area. :( * "Digital Art" * Grid and guides changed to some degree. * Rectangles and paths not changed. * Inkscape Designer Outcome: shapes and sizes are too small for the page :( * Cutter Software Outcome: shapes and sizes are correct :) * "Accuracy for masks and clips" * Grid and guides changed to some degree. * Rectangles, paths and strokes are changed to some degree, not the same as above. * Inkscape Designer Outcome: shapes and sizes correct right based on the page. :) (bug #1712114 does not occur.) * Cutter Software Outcome: File is significantly too small for cutting area. :( None of these options produce a svg that maintains its correct physical dimensions across both software packages. I tried experimenting by customizing the "units.xml" file in 92 without success. Here is my original v91 file zipped. (I added a background rectangle that is the size of the page to help troubleshooting.) https://www.dropbox.com/s/q6o17j5an2piiw3/acutra_TOCUTv91wBG.zip?dl=0 Is there anything that can be done? Thanks Jim

3 4

Changing width, triggers X axis movement
by Germano Massullo 24 Aug '17

24 Aug '17

I am sorry for not having opened a bugreport ticket in Launchpad, but actually Launcpad is experiencing malfunctions in logging process. At the following URL you can see a video example that shows the problem I am reporting: when trying to change width of selection, Inkscape instead changes X axis coordinates. https://youtu.be/Zcc4sq5U1gU inkscape-0.92.1-4.20170510bzr15686.fc26.x86_64 Best regards

2 4

Re: [Inkscape-devel] SVG in 92 and Phyisical Scale
by Jabier Arraiza 24 Aug '17

24 Aug '17

Hi James, Not only I program it but su_v and Tav do a great work on it. Just 96->90 if the document is converted at open. Cheers, Jabier. On Thu, 2017-08-24 at 15:19 +0000, James Fritzler wrote: > I have not tried it yet, but I see that you programmed it. It sounds > really useful! :) > > What steps should I use when I open the 91 file in 92 : Should I > first use the "digital art" option? and then use the 96 to 90 switch? > or should I try one of the other 2 options first (when opening the > old file)? > > > Thanks! > > > ________________________________ > From: jabier.arraiza@...2893... <javier.arraiza@...2893...> > Sent: Thursday, August 24, 2017 7:17:24 AM > To: Martin Owens; James Fritzler > Cc: Inkscape-Devel > Subject: Re: [Inkscape-devel] SVG in 92 and Phyisical Scale > > > Hi james, could you try the extension dpi switcher to convert to 90 > Dpi? > > > > Enviado desde mi móvil LG > > ------ Mensaje original ------ > De: Martin Owens > Fecha: 24/08/2017 15:10 > Para: James Fritzler; > CC: Inkscape-Devel; > Asunto:Re: [Inkscape-devel] SVG in 92 and Phyisical Scale > > > Hi James, > > It seems like the main issue is thrice fold: > > A) opening SVG 1.1 file means we have to convert it to SVG 2.0 dpi, > even though the spec isn't released, we've cut off the published spec > support too early. > B) We can't save physical units into the svg files themselves, > mitigating issues of external unit compatibility. > C) We don't have any capacity for users to change the way svg is > saved > to indicate which svg spec we should use. > > So we've got quite the compatibility problem. This isn't an issue if > one exports pdf files or printing to cut, but is a problem in this > case where the cutting software is consuming svg files directly. > > Tav and others: For 0.93, do we have a plan to try and help this > situation? > > If we can provide a way to save physical units and set svg 1.1 or svg > 2.0 outputs, we should be covering all bases. > > Best Regards, Martin Owens > > On 23 August 2017 at 11:10, James Fritzler wrote: > > Hi Inkscape Devs! > > > > > > I’ve used Inkscape for about five years now and have built up quite > > the > > library of svg files and have been using 91 since its release. My > > main > > creative effort is to build paper toys that I print and cut (in > > bulk) on a > > Silhouette Portrait cutting machine. (More info on my works at > > http://netroids.net ). I have a 100s of files and hoped to use > > them as my > > long term "masters” given that SVG is not proprietary and has had > > such great > > page layout fidelity for me. > > > > > > I’d love to update to v92 and future versions but, as is commonly > > known, the > > svg save logic has changed to support a new CSS standard of 96dpi > > and it is > > affecting my ability to import into my cutting software. > > > > > > It seems that perhaps the values written by Inkscape in 91 svg > > files are > > encoded using a 90dpi scale from their original design-time > > dimensions. In > > the past I’ve had much success importing SVGs from Inkscape 91 into > > Silhouette studio for years. (Granted, I do perform a little > > cleansing in a > > copy of the master svg before I go to Silhouette: I simplify the > > layers, > > ungroup, and flatten out clones into their own objects. Perhaps it > > is just > > serendipity that the Silhouette Studio imports SVGs at the > > 90dpi. (I tried > > asking them about dpi but I couldn’t "break through" their first- > > tier help > > desk support "fire wall".) > > > > > > I know there’s an import prompt and process for opening 91 files in > > 92 and I > > have participated in the launchpad forum and chat with Mc about > > this topic. > > (my user name is jimbox13). > > > > > > Unfortunate for me, none of the prompts give a workable > > solution. Here’s > > what happens to my files based on each option. (I used a diff tool > > in to > > investigate some of the changes.) > > > > "Accuracy for sizes and position of paths" (Desired option) > > > > Grid and guides appear to be changed – though I’m not sure to what > > extent. > > Rectangles, paths and strokes are sized up by 6.667% > > Inkscape Designer Outcome: shapes and sizes correct right based on > > the > > page. :) (bug #1712114 occurs.) > > Cutter Software Outcome: File is too large (by 6.667%) for cutting > > area. :( > > > > "Digital Art" > > > > Grid and guides changed to some degree. > > Rectangles and paths not changed. > > Inkscape Designer Outcome: shapes and sizes are too small for the > > page :( > > Cutter Software Outcome: shapes and sizes are correct :) > > > > "Accuracy for masks and clips" > > > > Grid and guides changed to some degree. > > Rectangles, paths and strokes are changed to some degree, not the > > same as > > above. > > Inkscape Designer Outcome: shapes and sizes correct right based on > > the > > page. :) (bug #1712114 does not occur.) > > Cutter Software Outcome: File is significantly too small for > > cutting area. > > :( > > > > None of these options produce a svg that maintains its correct > > physical > > dimensions across both software packages. I tried experimenting by > > customizing the "units.xml" file in 92 without success. > > > > > > Here is my original v91 file zipped. (I added a background > > rectangle that > > is the size of the page to help troubleshooting.) > > > > https://www.dropbox.com/s/q6o17j5an2piiw3/acutra_TOCUTv91wBG.zip?dl > > =0 > > > > > > Is there anything that can be done? > > > > Thanks > > > > > > > > Jim > > > > > > ----------------------------------------------------------------- > > ------------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

3 6

LXML & Windows
by Jabier Arraiza 23 Aug '17

23 Aug '17

Some users report me the complexity to install LXML on windows. Is posibol integrate it by default? Cheers, Jabier.

2 6

SMIL koi carp animation
by brynn 20 Aug '17

20 Aug '17

Hi Friends, I apologize, but I can't remember who made that SMIL koi carp animation image in the gallery. (User is shown as Unknown Author) I'm thinking Tav, but not positive. Anyway, note this recent comment: https://inkscape.org/en/comments/cr/621/5701/#c1569 I made reply comment that it has a copyright, but at last look, fish still swimming around on his website. I know we decided as a community not to bother with copyright issues in the gallery. But this time, it's one of us. So I just couldn't leave it alone. Although after this message, I am leaving it alone, and the artist can decide what to do :-) All best, brynn

3 2

should this remain in the gallery?
by brynn 20 Aug '17

20 Aug '17

Hi Friends, There's a recent new upload to the gallery, which appears to be instructions for using a website which helps people create their own logos, for a price. I can't see that it has anything to do with Inkscape (except in its PDF, it recommends using Inkscape to edit the logos). They could be considering the phrase in the CoC "made to be used with Inkscape" wrongly. But I'm not sure. (copying to the devel list, re CoC) I'm just looking for some other opinions about this, whether it should remain in the gallery at all, or remain under a different category. Personally, I think it's spam. But since I tend to be rather ruthless about spam, I thought I should ask for other opinions. Does anyone see any relationship to Inkscape here? Thanks, brynn

2 3

Not as awesome as....?
by brynn 20 Aug '17

20 Aug '17

Hi Friends, I happened to be looking through the Release Notes which now appear on the website, under each of the versions of Inkscape which are available for download. I noticed for some of the 0.48.x versions, under Known Issues, it says "Not as awesome as 0.91" For 0.48.3.1 it says "not as awesome as 0.49" which might be a clue these items were added around the time the decision was made to jump from 0.48 to 0.91. So apparently this was done on the wiki, and just made the transfer to the website recently. That doesn't sound especially professional to me. It sounds like a joke actually. Especially when there are no other known issues listed! (https://inkscape.org/en/release/0.48/?latest=1) If it's supposed to be some kind of motivation to upgrade, I think there probably is a more professional way to do it. I mean, it's not even a release note, since 0.91 was not made when 0.48.x was released. For goodness sakes! But I really think it should be removed. Or at the very least, re-worded. Is there some reason for that, which I haven't imagined yet? All best, brynn PS - I'd offer to delete them, except I don't appear to have access to those pages. Also, the about screen is not showing on the download pages for versions earlier than 0.48.5. Shall I make an Issue report? Or is someone currently working on it?

3 3