Problems building on Ubuntu 16.04
by mathog
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
4 years, 11 months
Stickers are here! ... now what?
by C R
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.
5 years, 3 months
Re: [Inkscape-devel] Embroidery extension
by Lex Neva
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...
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/>
>
5 years, 7 months
inkscape root dir tidying thoughts
by Bryce Harrington
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!
5 years, 7 months
Fwd: Re: Debian 8 compatibility falling apart after one month of Debian 9
by Michael Soegtrop
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
.
5 years, 7 months
Re: [Inkscape-devel] [Inkscape-user] inkscape-0.92.2pre0 - testers welcome
by brynn
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
5 years, 7 months
Re: [Inkscape-devel] cmake fails: unsupported Mingw
by Eduard Braun
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).
5 years, 7 months
Re: [Inkscape-devel] cmake fails: unsupported Mingw
by Jeff Mitchell
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_wit...
> (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
5 years, 7 months
cmake fails: unsupported Mingw
by 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.
5 years, 7 months
