- Inkscape Devel - Inkscape Mailman

2Geom sync status
by Krzysztof Kosiński 09 May '15

09 May '15

The 2Geom sync is almost done. So far I have identified two problem areas. 2Geom is now a lot more strict about what it considers a degenerate closing segment - it requires exact equality of endpoints, not just nearness to some arbitrary precision. This is of particular importance in paths where the last segment is curved. Because Inkscape loses precision when storing paths, bug #515237 now manifests on every closed path with a non-linear last segment. https://bugs.launchpad.net/inkscape/+bug/515237 I intend to fix this in the following way: first, modify SVGPathParser so that it knows whether the last segment before 'z' was relative, and if it is, snap it to the final node with a precision set by another function call, 1e-6 by default; second, by making Inkscape output paths with the double-conversion library now integrated in 2Geom and always using absolute coordinates, so that there is perfect roundtrip between XML and internal representation. This will mean the removal of the Output Precision setting and a moderate increase in file sizes. The proper place for such functionality is in a separate export filter. As a bonus, setting the document unit to metres will no longer cause a variety of issues. We discussed output precision briefly on the hackfest. Moving to full precision output with perfect roundtrip is the only correct solution and will enable us to avoid excessive recomputation of attributes in the SP tree, which is a performance win. If someone wants to get rid of extra precision - use an export filter. However, if anyone has a different opinion please speak up now. The second problem is the transformation of elliptical arcs, as seen when manipulating ellipses in the selector tool. In some cases, the large arc / sweep flags are incorrectly set for transformed arcs. I am still looking for the cause of this bug. The sync branch is at lp:~inkscape.dev/inkscape/lib2geom-sync - if anyone feels like looking for additional bugs, please do. I only did minimal testing on it. Regards, Krzysztof

4 12

non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner 09 May '15

09 May '15

ref : https://bugs.launchpad.net/inkscape/+bug/165665 I believe this bug can be fixed by disabling the flag USE_PANGO_WIN32 in line 19 of src/libnrtype/FontFactory.h. When I do this on Windows XP, I gain about 35 new fonts. Not all of these new fonts are useable, but the most interesting ones, such as CommercialPi, Symbol, Technic, Webdings, Wingdings, MonoType Sorts, TechnicLite are working well, both in Inkscape and in IE9. This is a Windows-specific bug which hides symbol fonts, and does not occur in Gimp 2.6 on Win XP. As far as I can tell, the Gimp source code does not contain any analogue or equivalent of the flag USE_PANGO_WIN32. Would there be any objection if I disable this flag, or does it serve a specific purpose that is essential? tia - Alvin Penner -- View this message in context: http://old.nabble.com/non-Unicode-symbol-fonts-do-not-work-on-Windows.-Bug-… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

7 16

Units
by Jabiertxo Arraiza Cenoz 09 May '15

09 May '15

Hi to all. Today I want to remove document units from effect.cpp/h to aboid crash noticed by Tav. Also remove units handle from fillet-chamfer and roughen LPE. Finaly there is two LPE harcoded to use "PX" as document units and we need to fix it: path_length and ruler Best of all, Jabier.

1 0

Glue together extension
by Christopher Saloman 08 May '15

08 May '15

I wrote a small extension to place multiple objects next to each other (with 0 distance to each other) vertically or horizontally as i need this quite often. Don't know if this is already implemented somewhere. But in case it isn't here is the code: https://github.com/mrsalo/inkscape_glue_extension

1 0

Inkscape_trunk_scan-build - Build # 72 - Unstable!
by Jenkins (build tester) 07 May '15

07 May '15

Hi developers, Clang scanbuild found a potential bug in recently committed code. Inkscape_trunk_scan-build - Build # 72 - Unstable. See here which bugs were found (new in red): http://jenkins.inkscape.org/job/Inkscape_trunk_scan-build/72/clangScanBuild… It is paramount to keep our codebase clean with as little compiler warnings as possible, so we can swiftly eradicate newly introduced bugs, to keep Inkscape stable and prevent lengthy dragging bug hunts before releases. Your friend, Jenkins http://jenkins.inkscape.org

3 12

Multilingual SVG
by Jabiertxo Arraiza Cenoz 06 May '15

06 May '15

Hi All. I want to improve switch work, to find a way to handle multilenguage SVG's. I try to explain whats in my mind to be improved with your thoughts. *current document is the default document. *When add a new lang, all contents is cloned/copied into a switch into his target lang. *I think clones are paths, ellipses, stars.... and copies are text elements and groups *Default document is moved to the default lang in switch. *Currently inkscape show the switch in current system lang, this behabiour is good for a viewer but we need a switcher for diferent langs, so the user pick the lenguage to use and inkscape reloads with this lang. Waiting to start, J.

3 2

patch test, causing crashes for another tester, not me
by insaner 04 May '15

04 May '15

I wrote up the following patch: https://bugs.launchpad.net/inkscape/+bug/1169123 And a user on IRC said they have a crash when adding a filter, I have no such crash and was wondering if someone could possibly shed some light on this. Their crash details: http://pastebin.com/FDaTFjwB http://pastebin.com/HHhq3KdQ http://pastebin.com/SSGPbfpb -- View this message in context: http://inkscape.13.x6.nabble.com/patch-test-causing-crashes-for-another-tes… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

Hackfest Q&A on git
by Bryce Harrington 04 May '15

04 May '15

On the last day of the hackfest, we discussed git over lunch. A few folks on IRC had questions about what we talked about, and I figured there'd be wider interest so am writing this up. What is motivating us to switch? Is bzr going away? Development of bzr has stopped. A couple years ago Canonical reassigned all the bzr devs to other projects, leaving just a skeleton staff to do bug maintenance (same was done with Launchpad). There had been a time when Canonical pushed bzr as the Cat's Meow, but I think the realization has sunk in that git has won the larger hearts and minds war. bzr is not going away though, near as I can tell. There's no urgency to move to something else; we can stay with it indefinitely if we want. But it's a dead end tool. As we recruit new developers we will find more often they have git experience but not bzr; eventually bzr will be a detriment to attracting new talent that will prefer to invest their skills in git. And there's no guarantee Canonical won't pull the plug on it at some point, regardless. There are also tons of tools, web applications, and so on being developed for git. What exists for bzr is in process of bitrotting away (e.g. I tried to install the rebase plugin last night but it's several bzr revisions out of date, and did not work.) Isn't git hard to learn? bzr seems so natural... git has a reputation for having a high learning curve, and it's legitimately earned. But most all of us have at least had a little exposure to git, and there are plenty of good tutorials out there. git was a struggle for me to learn, so I won't sugar coat it and say it'll be easy. But I will say if you haven't yet mastered git, then it's an important software development skill you're going to want to have beyond Inkscape anyway, since pretty much all other projects use it. What about Launchpad and its bzr integration? One of the reasons we picked bzr was because of its integration with the bug tracker, and yes that's pretty cool and something we'll lose making the transition. The good news is that unlike when we switched to bzr, there are now a number of good web apps and services (github clones, et al). So we'll have a wealth of options to consider when we get to this point. Where will we host the repository? github? freedesktop? One nice thing with git is that we will have 100% freedom in deciding where to host the official repo. We can even consider self-hosting it (e.g. on our website vm). We have lots and lots of options, and plenty of time to deliberate and decide on a plan. Can it import our history? tags? Yep. Lots of projects have preceeded us in bzr->git conversions and there's a rich set of well tested converter tools available. Can we still do PPA recipe builds on Launchpad? Sure can. Launchpad may only host bzr but it has a very good git importer. So we'd set up LP to import our git branch to a bzr tracking branch on LP and then it's business as normal. Can we convert to git ASAP? I know some people are anxious to move us over to git, and so am I, but we need to pace ourselves. Changing VCS is going to be disruptive to everyone, and it will take time before everyone's up to speed with it. As a project there are other changes which are more pressing, which we need to give priority to. If we rush into git, we're likely to make mistakes or at least cause unnecessary frustrations. Planned well, we can make the transition relatively smooth, and ensure there are tutorials and tips available as needed. Bryce

7 8

Re: [Inkscape-devel] Hackfest build-systems discussion]
by Ken Moffat 04 May '15

04 May '15

Whoops, replied to Bryce instead of to all. Let's try sending it to the list. On Sun, May 03, 2015 at 03:00:30AM +0100, Ken Moffat wrote: > On Sat, May 02, 2015 at 06:34:57PM -0700, Bryce Harrington wrote: > > On Sat, May 02, 2015 at 11:39:34PM +0100, Ken Moffat wrote: > > > On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington wrote: > > > > On Wed, Apr 29, 2015 at 02:51:15AM +0100, Ken Moffat wrote: > > > Yes, cmake -L appears to know what it is doing (noted some things I > > > > Building seemed to be going well, until > > > > > > [ 65%] Building CXX object > > > src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o > > > /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32: > > > fatal error: gtkspell/gtkspell.h: No such file or directory > > > compilation terminated. > > > > > > And when I look back at the cmake output it says: > > > -- checking for module 'gtkspell-2.0' > > > -- package 'gtkspell-2.0' not found > > > > What it's doing at that point is shelling out to pkg-config to see if > > gtkspell is installed. > > > > pkg-config --cflags --libs gtkspell-2.0 > > > > Run ^ that on your commandline and see what it says. If you don't have > > it installed, install it. :-) > > > I know I don't have it installed. If it is now required, I assumed > cmake would tell me. > At this point, I'm looking at r14094. If you will accept that, for the moment, using ./autogen.sh and configure is still a valid comparison, then gtkspell is optional. With autogen.sh and configure I've managed to build it - no sign of gtkspell (nor the coreldraw, vision, whatever) stuff. Some hours later, after copious swearing (is that required or does it only seem to help ? ;-), I think I've found where the problem is. With the following patch, I can cmake, build and DESTDIR install inkscape and the man pages, without any additional -D magic. I will note that inkview did not get installed. I would have thought that the set line I deleted would have done the right thing, but for me it didn't. If this is acceptable, do you need a SoB or equivalent ? ĸen --- inkscape/CMakeScripts/DefineDependsandFlags.cmake.orig 2015-05-03 22:06:01.598985260 +0100 +++ inkscape/CMakeScripts/DefineDependsandFlags.cmake 2015-05-03 22:08:03.313995015 +0100 @@ -290,8 +290,9 @@ list(APPEND INKSCAPE_INCS_SYS ${GTKSPELL_INCLUDE_DIR}) list(APPEND INKSCAPE_LIBS ${GTKSPELL_LIBRARIES}) add_definitions(${GTKSPELL_DEFINITIONS}) + else() + set(WITH_GTKSPELL OFF) endif() - set(WITH_GTKSPELL ${GTKSPELL_FOUND}) endif() #find_package(OpenSSL) ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.

2 1

cmake next steps
by Bryce Harrington 03 May '15

03 May '15

Several of us now are able to successfully build Inkscape using cmake only. This is still relatively new, but we need to broaden this to everyone and make sure it works universally. Do a 'make distclean' in your repo, update to latest bzr, and then: $ cmake . $ make -j8 Hopefully this "just works". If not, read on for troubleshooting tips. CMakeCache.txt is a listing of all configurable parameters and all computed values. For settables, you can force them via: $ cmake -D<VARIABLE>=<VALUE> If the build craps out during build or linking due to some missing bit or other, reviewing this file can indicate if it has misdetected an include or library path or whatnot. CMakeList.txt is the top level build script, and generally the place to start for debugging problems. This also is where all configurable option parameters should be defined. There is also a src/CMakeList.txt where the source files and header files are itemized. This also sets up rules for compiling and linking the executable and its libraries. Similar CMakeList.txt files are placed in other directories with source. The CMakeScripts/ directory holds various helper functions. In this directory is a Modules subdirectory; this is where the logic is held that finds where various dependencies have their include and library files located. If you get errors about dependency headers not found during build, or during linking it can't find definitions of symbols then there could be an error in one of the Module Find*.cmake files. CMakeScripts/DefineDependsandFlags.cmake is another important file; this is where the include path and library options are worked out. This file is essentially the "glue" that utilizes all the Modules, and propagates settings up to the top level script. Beyond this, there is a wealth of cmake tips and examples on the web, so google will be your friend. ------------------------------------------------------------------------ So what development needs done? While the cmake scripts work, they're a bit hacky and in need of some cleanup. Below is a laundry list. I'd encourage everyone to tackle a task or two, to get some cmake familiarity if nothing else. Once this work is all done, we can wrap up 0.92 and start the release process. 0. Cleanup definitions. In CMakeLists.txt there are a sequence of add_definitions() to set some environment variable definitions. Some of these may not be strictly needed, others could be moved to DefineDependsandFlags.cmake or to the respective Modules files. 1. Win32. Someone needs to try this against our supported win32 platforms, and fill in the missing logic that is specific to Win32. 2. More files. A lot is missing from the build... tests, man files, icons, locale. If it's not clear how to do the logic for this stuff, refer to another cmake-based project. 3. More Modules. In DefineDependsandFlags.cmake we just brute force several libraries (to pick a few examples: pangocairo, gthread, gomp, gslcblas...) These need to have proper Find<Library>.cmake scripts made. Generally these are pretty easy - just make it wrapperize pkgconfig. FindGtkSpell.cmake has a simple example. Google "cmake <library>" before you do any work though; sometimes someone has already done the logic and you can just copy. 4. Update Modules. Several of our modules were taken from cmake or elsewhere, a long time ago, and they've improved upstream since then. Snag newer versions, test, and add to our codebase. If we have local changes consider pushing those upstream. 5. Add more configuration options. Review what we offer in automake and make sure the equivalents are defined in CMakeLists.txt 6. Verify that uninstall works 7. Fix dist. In CMakeLists.txt it adds a custom svn command; this needs replaced with the equivalent bzr. And in general run 'make dist' and hack on it until it produces a proper tarball. 8. Identify other issues needing resolved. I notice FIXME's peppered here and there in various files. We'll want to tackle those or at least plan those tasks for later on. Bryce

3 2