Re: [Inkscape-devel] Embroidery extension
by Michael Soegtrop
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
3 years, 9 months
New Team Icons: Highlight
by Martin Owens
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
3 years, 9 months
Re: [Inkscape-devel] Embroidery extension
by Michael Soegtrop
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/>
3 years, 9 months
Re: [Inkscape-devel] Embroidery extension
by Susan Spencer
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
3 years, 9 months
inkscape-0.92.2pre0 source tarball now available
by Bryce Harrington
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
3 years, 9 months
Re: [Inkscape-devel] [Inkscape-board] Paint is dead; long live Inkscape
by Martin Owens
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
3 years, 9 months
Fwd: Inkscape freezing while adding grid.
by Christophe Lebras
---------- 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
>
3 years, 9 months
Debian 8 compatibility falling apart after one month of Debian 9
by Michael Soegtrop
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 years, 9 months
Proposed schedule for 0.92.2 release
by Bryce Harrington
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
3 years, 9 months
