- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Embroidery extension
by Michael Soegtrop 30 Jul '17

30 Jul '17

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

New Team Icons: Highlight
by Martin Owens 30 Jul '17

30 Jul '17

Dear Developers and Users, I have been working with Tim Jones to develop some new icons for the website. I wanted the icons to have a theme and to carry a bit of identity for the teams they represent. So we went with hats. See the lovely icons in-situ here: https://inkscape.org/en/teams/ Showing off the art is actually not just what I want to communicate. Firstly I want to thank Tim, because they have been awesome to work with and very productive with the brief. I highly recommend. I approached Tim because he'd produced a piece of artwork with Inkscape and submitted it to our website (inkscape.org). The way we can host a small portion of our user's work on the website, is really something great for our community. Firstly because it shows us what great things can be done with the software, but also because it humbles us developers to know that our code is helping make such amazing work. Getting new collaborators into a project is hard. Getting non- programmer contributions is harder still. But the way our website can highlight non-developer aspects of our community; gifts us an opportunity to expand the reaches of the contributing population, to bring in new people and help them contribute in whatever small way they can. If you find yourself browsing the website, and you get an idea about how we might make the user community even better through improvements to the how the website works. I want you to let me know. Because users are just as important as developers, and helping people come together helps all parts of the project. Thanks for listening! Best Regards, Martin Owens Website Administrator

7 6

Re: [Inkscape-devel] Embroidery extension
by Michael Soegtrop 30 Jul '17

30 Jul '17

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/>

1 0

Re: [Inkscape-devel] Embroidery extension
by Susan Spencer 28 Jul '17

28 Jul '17

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

1 0

inkscape-0.92.2pre0 source tarball now available
by Bryce Harrington 27 Jul '17

27 Jul '17

The first (and hopefully only) pre-release package for the upcoming 0.92.2 release is now available: https://inkscape.org/en/gallery/=inkscape-package/0922pre0/ The 0.92.x branch should now be considered in Hard Freeze + String Freeze. Code changes to the 0.92.2 branch should be sent to me for review and landing (see below.) Translations can be landed normally up to the 4th of Aug. --- I intended to get this released last weekend, but the dist process has changed significantly with the git migration and needed a bit of TLC. suv, liam, Eduard, QuLogic, and others have provided much advice and assistance getting things adapted - thank you. Specifically, we're moved from using `bzr export` to `git archive` for producing the dists. In theory this should be an equivalent move, but please keep your eyes peeled for any missing files or release-specific details that failed to get updated. While there are more enhancements that could be done(*) to streamline the dist code, in the interest of stability, predictability, and expediency I'm going to postpone those to after the release. The dist modifications also need ported to trunk. If anyone's interested in doing this let me know and I'll explain how it should be done, otherwise I'll try to get it taken care of later. The release will be in approximately 2 weeks. I'm thinking a release coordination meeting following the upcoming board meeting may make sense; I'll send an invite later. At this time, despite my delay getting pre0 out, I think the schedule outlined below can still be achieved; contact me if you know of any factors that need to be taken into account. Bryce * - Notably, QuLogic suggested using gitattributes to substitute the commit hash and date in inkscape-version.cmake, instead of inserting it via set and then temporarily committing. This would be far cleaner than the hack I've added. ------------------------------------------------------------------------ Date: Sat, 15 Jul 2017 22:23:07 -0700 From: Bryce Harrington <bryce@...961...> To: inkscape-devel@...6... Subject: [Inkscape-devel] Proposed schedule for 0.92.2 release We were holding off for 0.92.2 until the git migration was done. Now with that behind us, I'd like to suggest some plans for doing another point release: Jul 22: 0.92.x Pre-release + String Freeze (0.92.x branch only) + Packagers package pre0 release as desired + Translators work on translations + Revert changes that introduced regressions + Code changes must be reviewed and landed by Bryce (0.92.x branch only) Aug 4: Final Freeze + Final deadline for all translation work + Only Release Warden may commit (0.92.x branch only) Aug 5: 0.92.x Release Tarball + Packagers package final tarball Aug 7: Announce Backporting of fixes has been going strong (good work everyone!) Please keep doing as you've been doing for one more week. After the 22nd, I will be reviewing and landing all further code-changing patches. You can send me merge requests, lists of cherrypickable SHA's from trunk, or patchsets generated via `git format-patch`, as is convenient for you. Stuff I'll be watching for: ☑ Patch is short ☑ Fix is already in trunk ☑ Has been tested and confirmed by at least one other person ☑ References a bug ID or url in commit message ☑ No translatable strings are changed ☑ Bugfix only - no refactoring, no feature changes On the 22nd, I'll package a pre0 tarball for testing purposes. The switch to git will require updating some release procedures so this will be a good dry run. It would be nice to see packages made. Testing of the pre-release will be appreciated, however for release purposes we will be principally looking for _regressions_ compared with 0.92.1, so we can revert whatever patch caused the regression. Other bugs are welcome to be filed and worked on, of course, but I'd like to keep on schedule. For the actual release, please take Aug 5th as a pencilled in date, that may need to change depending on how things go. When the tarball is ready I'll send a private note to the release team (packagers + announcers). Vector Team, if you would like to take the announcement writing and/or dissemination tasks, let me know - I'd be very appreciative of the help. Let me know if there is anything else that should be done or accounted for in the above plan. Bryce

7 11

Re: [Inkscape-devel] [Inkscape-board] Paint is dead; long live Inkscape
by Martin Owens 25 Jul '17

25 Jul '17

Alex I've moved this to the devel channel since it's not a board issue. Reply below. On Mon, 2017-07-24 at 15:37 +0100, Alex Valavanis wrote: > Hi All, > > Would it be inappropriate to make some kind of Social Media push to > try and catch some MS Paint users now that MS have marked it for > destruction? > > http://www.bbc.co.uk/news/technology-40705466 > > I know Paint isn't a vector editor, but there might be some casual > sketchers who'd be interested to know what their options are :) This is what I would do, but it's more of a blog entry: As an Artist, the tools that we use are an important way of working. They inform the art we make, provide the feel and texture that's created from the limitations of the medium. In software, we have a curious contemptible situation. One where your art tools can be taken away from you by a software corporation. That you were using the tool to make art is not a consideration to them, only that the costs to them of maintaining them have gotten high enough for them to cut the chord. Recently Microsoft have decided to decommission MS Paint. It's a simple tool which has a history going back to 1985, and while it's no Gimp or Photoshop, it does have it's own style which many artists still use to great effect. But now it's being discontinued. Inkscape had a similar problem back in it's history. Back before it was called Inkscape. Development of a vector art tool had become too difficult for one developer, and setting up a project to collaborate is a lot of work. But there was a need from artists to continue the project and not let it die. From Artists came the continuation of the software, many many years after the original developer had stopped working on it. It was only possible to do this because Inkscape is Free Software. Meaning it gives you, the artist, the user, the unequivocal right to own in a fundamental fashion the software tool that you use. If you want to take Inkscape's code, and move it in a different direction, you can. Ponyscape did. If you want to continue the project on past the life of the developers currently working on it, you have that freedom. Either through developing your own code, or by hiring people to work on it for you. The big point here is that Inkscape will never die. So long as there is an Artist that wants to draw or an engineer that wants to cut designs. There will be an Inkscape project. It can not be killed by a corporation, it can't be killed by the copyright holders, you and your friends can continue the project no matter what authority says. It would be best if Microsoft granted the same Freedoms to their users, that we do to ours. The Free Software ideal is that users should always have these Freedoms, but for now we will have to recreate and reinvent proprietary software each time it's discontinued and encourage users to ALWAYS demand that the software they use grant freedom to them. Even if they get that software from Microsoft, Adobe or anyone else. (For MSPaint alternatives, see http://alternativeto.net/software/microsoft-paint/?license=opensource) Thoughts? Best Regards, Martin Owens

6 14

Fwd: Inkscape freezing while adding grid.
by Christophe Lebras 25 Jul '17

25 Jul '17

---------- Forwarded message ---------- From: Christophe Lebras <christophe.lebras@...400...> Date: 2017-07-25 17:38 GMT+01:00 Subject: Re: [Inkscape-devel] Inkscape freezing while adding grid. To: Maximilian Gaukler <development@...3069...> Hi, Here is the dockerfile. I think the two problems are related: When I did a backtrace in the debugger for each problem, I saw that the main thread is waiting for a mutex in jemalloc. When I disabled thread-specific cache in jemalloc with the command below, the problem disapear. MALLOC_CONF='tcache:false' ./bin/inkscape ... Best regards Christophe 2017-07-21 21:22 GMT+01:00 Maximilian Gaukler <development@...3069...>: > Hi, > > A similar freeze which only appears with jemalloc, and not on > Debian/Ubuntu, was reported as a regression in > https://bugs.launchpad.net/inkscape/+bug/1417470 , although AFAIK the > freeze is caused by jemalloc and not the patch in that bug. > > Christophe, could you please try if that freeze also affects you? Just run > these two commands: > > curl -L https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1417 > 470/+attachment/4908832/+files/test.svg > test.svg > > ./bin/inkscape -z -D --file=test.svg --export-pdf=test.pdf --export-latex > # will freeze and not return if the bug happens. > > If you get the error, a dockerfile or any working description on how to > compile Inkscape under the relevant distribution(s) would be extremely > helpful. > > > Thanks, > > Max > > ------------------------------------------------------------ > ------------------ > 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 >

1 0

has there been a change in the cmake/devlibs build instructions?
by alvinpenner 25 Jul '17

25 Jul '17

previously, according to the instructions at: https://inkscape.org/en/develop/getting-started/#building-inkscape-windows I would execute the commands: md build cd build cmake -G "MinGW Makefiles" .. mingw32-make -j 2 mingw32-make install Now it appears that the command 'mingw32-make -j 2' is redundant, and all that is needed is the sequence: md build cd build cmake -G "MinGW Makefiles" .. mingw32-make install I found this out by accident while trying to compile the 0.92.x branch revision 84f9b04a from July 24 on Windows XP using devlibs and cmake. All the source code got compiled twice using the original set of commands. When I deleted the build directory and removed the redundant make command, it compiled normally. The same appears to be true in trunk as well. Alvin -- View this message in context: http://inkscape.13.x6.nabble.com/has-there-been-a-change-in-the-cmake-devli… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 4

Debian 8 compatibility falling apart after one month of Debian 9
by Michael Soegtrop 24 Jul '17

24 Jul '17

Dear Inkscape Team, I wanted to start a general discussion on compatibility. I um using Debian 8. Ok maybe I shouldn't since Debian 9 is out since a month (June 17th, 2017), but I still like it. My problem is that in the last week quite a few changes came in, which are not compatible with Debian 8: - Requirement for CMake 3.2+ (Debian 8 has 3.0.2) specific syntax of add_custom_target - Requirement for GTK 3.16 (Debian 8 has 3,14) use of gtk_label_set_xalign - Requirement for some rather late libg++ using isinf without :: or std:: qualifier See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891 Not sure which version introduced the fix, but Debian 8 doesn't have it. The first two are just build issues, but the GTK issue will result in binary incompatibilities. I just did an update to master after a week and now sitting here since two hours to get it build again (there were some additional dependencies added last week which are ok in Debian 8 but still required installing the packages). The build stopped now at 59%, not sure how much is still ahead. Is this wanted that compatibility with the previous version of Debian breaks after one month? On what kind of system do the CI tests run? Ubuntu 16.04? Best regards, Michael

3 2

Proposed schedule for 0.92.2 release
by Bryce Harrington 24 Jul '17

24 Jul '17

We were holding off for 0.92.2 until the git migration was done. Now with that behind us, I'd like to suggest some plans for doing another point release: Jul 22: 0.92.x Pre-release + String Freeze (0.92.x branch only) + Packagers package pre0 release as desired + Translators work on translations + Revert changes that introduced regressions + Code changes must be reviewed and landed by Bryce (0.92.x branch only) Aug 4: Final Freeze + Final deadline for all translation work + Only Release Warden may commit (0.92.x branch only) Aug 5: 0.92.x Release Tarball + Packagers package final tarball Aug 7: Announce Backporting of fixes has been going strong (good work everyone!) Please keep doing as you've been doing for one more week. After the 22nd, I will be reviewing and landing all further code-changing patches. You can send me merge requests, lists of cherrypickable SHA's from trunk, or patchsets generated via `git format-patch`, as is convenient for you. Stuff I'll be watching for: ☑ Patch is short ☑ Fix is already in trunk ☑ Has been tested and confirmed by at least one other person ☑ References a bug ID or url in commit message ☑ No translatable strings are changed ☑ Bugfix only - no refactoring, no feature changes On the 22nd, I'll package a pre0 tarball for testing purposes. The switch to git will require updating some release procedures so this will be a good dry run. It would be nice to see packages made. Testing of the pre-release will be appreciated, however for release purposes we will be principally looking for _regressions_ compared with 0.92.1, so we can revert whatever patch caused the regression. Other bugs are welcome to be filed and worked on, of course, but I'd like to keep on schedule. For the actual release, please take Aug 5th as a pencilled in date, that may need to change depending on how things go. When the tarball is ready I'll send a private note to the release team (packagers + announcers). Vector Team, if you would like to take the announcement writing and/or dissemination tasks, let me know - I'd be very appreciative of the help. Let me know if there is anything else that should be done or accounted for in the above plan. Bryce

4 7