July 2017 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Problems building on Ubuntu 16.04
by mathog 24 Apr '18

24 Apr '18

Upgraded the Ubuntu 14.04 system which had endless build problems to Ubuntu 16.04. It doesn't seem to like 16.04 much better. Different problems, but still problems. Cleaned out the build directory and did: cmake .. which failed at ... WITH_OPENMP: ON WITH_PROFILING: OFF WITH_YAML: OFF ------------------------------------------------------------------------ CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: POPPLER_INCLUDE_DIR used as include directory in directory /usr/local/src/inkscape_trunk used as include directory in directory /usr/local/src/inkscape_trunk used as include directory in directory /usr/local/src/inkscape_trunk used as include directory in directory /usr/local/src/inkscape_trunk <SNIP many lines> -- Configuring incomplete, errors occurred! See also "/usr/local/src/inkscape_trunk/build/CMakeFiles/CMakeOutput.log". This is at revision 15617. These poppler pieces are present ii gir1.2-poppler-0.18 0.41.0-0ubuntu1 ii libpoppler-dev:i386 0.41.0-0ubuntu1 ii libpoppler-glib-dev 0.41.0-0ubuntu1 rc libpoppler-glib4 0.12.4-0ubuntu5.2 ii libpoppler-glib8:i386 0.41.0-0ubuntu1 rc libpoppler19:i386 0.18.4-1ubuntu3.1 rc libpoppler44:i386 0.24.5-2ubuntu4.4 rc libpoppler5 0.12.4-0ubuntu5.2 ii libpoppler58:i386 0.41.0-0ubuntu1 ii poppler-utils 0.41.0-0ubuntu1 What needs to be tweaked to make this work? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 4

Stickers are here! ... now what?
by C R 12 Dec '17

12 Dec '17

The stickers arrived today. They are of acceptable quality, but I think 300dpi is a little low quality for stickers this small. Also I think the cutting machine had some ink residue, because the border of stickers are a bit dirty on the cut. So, who wants/needs stickers? I have a request for a sheet of the coffee and sheet of the ice cream already. Did we have any solid plans for these yet? See attached for samples.

6 9

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

inkscape root dir tidying thoughts
by Bryce Harrington 15 Aug '17

15 Aug '17

With the cmake and git conversions complete, and autotools and bzr bits removed, I am wondering if there's some additional cleanup of stuff accumulated in our repository's root directory. But much of this I'm not 100% sure about (and that maybe why others haven't already dealt with it). ------------------------------------------------------------------------ + distro + libgc.supp + tools-version.sh I think these may be obsolete. They've been in the codebase forever, but I don't know what they are used for anymore. I'm guessing they're autotools leftovers; can we drop them? ------------------------------------------------------------------------ + inkscape.ico + inkscape.png The share/icons/application/ directory is the formal place for our icons, with share/branding/ the official source for branding files. Only the windows packaging refers to inkscape.ico. So I think this could be moved to packaging/. Or perhaps windows could be changed to use the .png files like everything else? Doxyfile seems to reference inkscape.png but I believe it could as easily use one of the icons in share/icons/application/, but see below... ------------------------------------------------------------------------ + Doxyfile This doxygen config file works fine (just ran it). However according to http://wiki.inkscape.org/wiki/index.php/Doxygen_documentation we aren't posting doxygen pages online any more. In any case, doxygen lets you pass the config file name on its command line, so no reason this has to live in the root directory. Unless anyone has strong feelings otherwise I propose moving this file to doc/ with our other code/architecture docs. Or... other ideas? ------------------------------------------------------------------------ + inkscape.spec.in This is an old RPM build file I made way way back. I'm sure Fedora has something better, and besides this is _completely_ out of date. I will be deleting it. ------------------------------------------------------------------------ + inkscape.desktop.in + inkscape.desktop.template Is inkscape.desktop.in generated from inkscape.desktop.template? Do we need both files? ------------------------------------------------------------------------ + mingwenv.bat + mingwenv.cmake + msys2checkdeps.py + msys2installdeps.sh + msysenv.sh + inkscape.appdata.xml.in + Info.plist.in + appveyor.sh + appveyor.yml + .gitlab-ci.yml + .snapcraft.yaml + packaging/ I know a lot of tools expect config files in the project's root directory, but can any of these be moved to packaging/? (Or maybe a utils/ dir?) Several of these have description snippets that are essentially the first few paragraphs of the README. If the README is revised (see below), it may be worthwhile to resync the text in these from that. ------------------------------------------------------------------------ + download-gtest.sh This still seems necessary for setting up gtest (although current trunk breaks on configure due to lack of a "Findgtest.cmake"; but that seems unrelated). Having to use this script has always seemed a bit hacky to me. (and it's downloading gtest 1.7, but 1.8 is current). I know there's been some good work done on improving our testing cmake rules, I wonder if there is a way we can eliminate this script? ------------------------------------------------------------------------ + testfiles/ Speaking of tests... Is there a reason why we call this directory testfiles/ rather than a more traditional name like 'test/' or 'tests/'? ------------------------------------------------------------------------ + INSTALL The installation directions here are for autotools so the whole file is obsolete. I only hesistate to delete it because I believe `make distcheck` requires it. So question here is should we move the installation directions currently in the README.md file to INSTALL? ------------------------------------------------------------------------ + README.md + README.ca.txt + README.de.txt + README.es.txt + README.fr.txt + README.it.txt + README.pt_BR.txt + README.sk.txt + README.sr.txt Speaking of the README, we've had these translations of the README for a long, long time. Most have not been updated to reflect the autotools -> cmake move, some haven't been updated in a decade. None have followed the main README's reformatting to markdown. But I wonder if translations of the README are that necessary? If not, would anyone be troubled if we dropped them at this point? Aside from the installation directions (which are out of date anyway, and maybe should move to INSTALL), the information in the README is just introductory stuff that exists in translated form on our website and elsewhere so The first section of the README we have used far and wide all over the place. It's a stock text we cut and paste into anything that needs a description of our project. But it's been pointed out to me that this doesn't really reflect the current state of Inkscape and all the stuff that's been achieved since it was written. So, we may want to consider revising this. Does anyone know of a more current description of Inkscape that we could leverage for this? ------------------------------------------------------------------------ + inkscape.pod + inkscape.de.pod + inkscape.el.pod + inkscape.fr.pod + inkscape.ja.pod + inkscape.sk.pod + inkscape.zh_TW.pod + inkview.1.in + man/ Unlike the README's, the translated man pages have been getting updates. The --no-convert-text-baseline-spacing option is only documented in the English inkscape.pod, but the previously added option, --export-ps-level, (from 2013) is present in all. However, these should move down into the man directory. The CMake code is already in CMakeLists.txt to generate the .pod files from the man/ directory, so recent changes to the root *.pod's just need to be sync'd with the corresponding files in man/ and then removed. As an aside, I know we eliminated Perl from the build system, but it's still used for the man page generation (the 'p' in pod stands for perl). I like the POD format, but raw man page syntax (TROFF) isn't *that* complicated; if we wanted, we could just keep all the man pages as troff, eliminate pod usage, and simplify our build requirements. (Compare inkview.1.in with man/inkview.pod.in to see the difference). Would anyone be opposed (or favorable) to this change? ------------------------------------------------------------------------ + fix-roff-punct + utf8-to-roff These perl scripts were used to fix up punctuation goofs by pod2man. If we moved away from POD, then these are entirely superfluous and can be dropped. -------------- + COPYING + GPL2.txt + GPL3.txt + LGPL2.1.txt Next, licenses... As detailed in the COPYING file, the only reason we have GPL3.txt is because there's a few files in our tree copied from GIMP. Could someone please take the task of eliminating those files, so Inkscape can return to being pure GPL2? The LGPL2.1 isn't a problem, but according to COPYING it's only there due to some libs we copied into the tree (I see libavoid is LGPL, is there anything else?) If the LGPL libs were changed to be external dependencies instead of copied into src, we could eliminate the LGPL2.1.txt file too. ------------------------------------------------------------------------ + CMakeLists.txt + CMakeScripts/ + cmake_uninstall.cmake.in + config.h.cmake CMake is nice and concise compared to autotools. I do wonder if cmake_uninstall.cmake.in could perhaps be moved into CMakeScripts/. If anyone else wants to move it, please do, else I'll look into it some time. ------------------------------------------------------------------------ + astylerc This config file appears to be for a code formatting tool. I vaguely remember kk discussing it a while back. Is anyone still using it? The astyle man page indicates it supports using --options=FILENAME to specify a path to astylerc, so the file could be moved to utils/ or elsewhere. I see we already have the options documented at https://inkscape.org/en/develop/coding-style/ including directions for how to store the settings locally in ~/.astylerc. If no one is actively using this tool, that might be a better solution and remove astylerc from the codebase. ------------------------------------------------------------------------ + _clang-format I'm not sure why this is in the tree. Guessing it was a jenkins-related thing? I suspect we can drop this. ------------------------------------------------------------------------ + setup/ This appears to be current, but what is it? It has a single subdir with a single file, which looks like a copy of inkscape.desktop.in with translations embedded. Why is this in a directory called 'setup'? ------------------------------------------------------------------------ + ChangeLog With the newest entry in this file being from 2014, this looks vestigal. I think it used to be needed for packaging, and I think it dates to pre-bzr. Anyone know if there's a reason to keep it? ------------------------------------------------------------------------ + AUTHORS + TRANSLATORS + NEWS + doc/ + share/ + src/ + po/ This is all pretty stock, no comment here. Bryce P.S. if you've read to this far, thanks! This ended up way longer than I anticipated, sorry!

13 35

Fwd: Re: Debian 8 compatibility falling apart after one month of Debian 9
by Michael Soegtrop 11 Aug '17

11 Aug '17

Dear Eduard, dear Inkscape Team > If this version matches the actual requirement unexpected build failures > like Michael was experiencing should be impossible as cmake would > already warn at the configure stage. I would think that CMake allows newer versions than the specified one, unless explicitly told otherwise. The issue here is that some GTK 3.16 are actually used although only GTK 3.8 features should be used (as far as I understood). I have some experience with creating build systems which use specific package versions based on Cygwin. Since there is a working MSys build, it shouldn't be difficult to build with specific package versions - one just has to create a local cygwin or MSys package repository, which keeps these specific versions and tell the Cygwin/MSys installer to use that one. The Cygwin installer creates a suitable repository as a cache automatically. Not sure how this works with MSys, but I guess it has similar features. The main issue here might be to get the versions mentioned in the Wiki. One might have to build them from scratch. If someone has a years old cache folder of Cygwin or MSys with all the old package versions, please put is somewhere. It would make sense to run two builds, one with the latest packages and one with an archived set of packages. Best regards, Michael .

6 16

Re: [Inkscape-devel] [Inkscape-user] inkscape-0.92.2pre0 - testers welcome
by brynn 09 Aug '17

09 Aug '17

I'm not sure where we are with the new vectors team. But hopefully starting with the next release, it will be organized enough to handle making the announcments. Meanwhile, would you like a News items for this? I was just about to make posts in forums, but maybe a News item would would be helpful as well? All best, brynn -----Original Message----- From: Eduard Braun Sent: Wednesday, July 26, 2017 3:27 AM To: inkscape-user@...6... Subject: [Inkscape-user] inkscape-0.92.2pre0 - testers welcome Am 26.07.2017 um 01:06 schrieb 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/ Hi all Bryce just released the source tarball for the 0.92.2 pre-release (see above), the final release is to be expected around Aug 7th. I want to invite you all to test the pre-release. Especially the builds for Windows should receive some extensive testing as I switched the build system for this release (it's now built with MSYS2 instead of our custom-built devlibs for those interested in the details). Overall this should result in less bugs, some additional features and maybe even slightly improved performance, but - as with all fundamental changes - it might have introduced regressions we're not aware of. Therefire please let me know if you find any new issues that might block this release (we'll fall back to the way we built Inkscape before in this case). A full set of Windows builds (7z, exe, msi - x86/x64) is available from: https://inkscape.org/en/~eduard.braun/galleries/inkscape-0922pre/ Regards, Eduard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

15 23

Compiling Inkscape on Windows 10 with Visual Studio Community 2017
by Ivano Arrighetta 07 Aug '17

07 Aug '17

As in the subject, how do I compile Inkscape on Windows 10 using Visual Studio Community 2017? Thanks in advance for any help. Bye, Ivano.

2 1

Re: [Inkscape-devel] cmake fails: unsupported Mingw
by Eduard Braun 31 Jul '17

31 Jul '17

Am 31.07.2017 um 14:46 schrieb Jeff Mitchell: > Do I need different versions of mingw, installed side-by-side? If you use MSYS2 there's no need to install any other dependencies. MSYS2 ships with mingw-w64 toolchains for both 32-bit and 64-bit builds (you don't need both if you only want to target one architecture).

1 0

Re: [Inkscape-devel] cmake fails: unsupported Mingw
by Jeff Mitchell 31 Jul '17

31 Jul '17

Do I need different versions of mingw, installed side-by-side? Sent from my phone On 31 Jul 2017 21:39, Eduard Braun <eduard.braun2@...173...> wrote: > > Am 31.07.2017 um 07:28 schrieb Jeff Mitchell: > > Bad result from cmake .. command: > > > > Unable to determine MinGW processor architecture. Are you using an > > unsupported MinGW version? > > > > I put MinGW exactly where it's needed - in C:\ and without whitespace > > characters. How do I fix this? There's nothing on Google that will > > explain it. I'm using the normal MinGW, not a legacy version or beta. > > Hi Jeff, > > as Inkscape has a lot of dependencies you can't just use any version of > MinGW. > > The currently recommended (and if you want to compile the current git > master only) way is to compile with MSYS2, see > http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_with_… > (ignore the bzr parts, that information has yet to be updated) > > For 0.92.x you can still use our pre-compiled "devlibs" (or "devlibs64" > respectively) with steps detailed at > http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows and > http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit > but the also need specific versions of mingw(-w64) and won't work with > any compiler due to ABI incompatibilites. > > If you have further questions let us now. > > Regards, > Eduard

1 0