- Inkscape Devel - Inkscape Mailman

Bug fixed testing
by Jabiertxo Arraiza Cenoz 07 Jun '14

07 Jun '14

Hi to all. I just commit to experimental a fix to the bug https://bugs.launchpad.net/inkscape/+bug/1241902 to the experimental branch, every body are welcome to test it previous to commit to trunk. Thanks to Johan for his persistence in reviews.

1 0

Problem compiling experimental with CMake
by Liam White 06 Jun '14

06 Jun '14

Apologies for the wall of text. liam@...3128...:/home/inkrepo$ cd experimental liam@...3128...:/home/inkrepo/experimental$ ls liam@...3128...:/home/inkrepo/experimental$ cmake . -- Creating build files in: /home/inkrepo/experimental -- Found GSL: /usr/lib/libgsl.so -- Found BoehmGC: /usr/lib/x86_64-linux-gnu/libgc.so -- Found poppler: /usr/lib/x86_64-linux-gnu/libpoppler.so -- Found poppler-glib: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so -- Found cairo-svg: /usr/lib/x86_64-linux-gnu/libcairo.so -- Found poppler-cairo: /usr/lib/x86_64-linux-gnu/libcairo.so -- checking for module 'libwpg-0.1' -- package 'libwpg-0.1' not found -- checking for module 'libwpg-stream-0.1' -- package 'libwpg-stream-0.1' not found -- checking for module 'libwpd-0.8' -- package 'libwpd-0.8' not found -- Found libwpg-0.2: /usr/lib/libwpg-0.2.so -- Found libwpd-0.9: /usr/lib/libwpd-0.9.so -- Found libwpd-stream-0.9: /usr/lib/libwpd-stream-0.9.so -- Found Popt: /usr/lib/x86_64-linux-gnu/libpopt.so -- Boost version: 1.54.0 -- checking for module 'gtkspell-2.0' -- package 'gtkspell-2.0' not found -- Try OpenMP C flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS) -- Generating header and sourcefiles from sp-marshal.list (Glib-Marshal) -- sp-marshal.h unchanged 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: ImageMagick_MagickCore_INCLUDE_DIR used as include directory in directory /home/inkrepo/experimental used as include directory in directory /home/inkrepo/experimental used as include directory in directory /home/inkrepo/experimental/src used as include directory in directory /home/inkrepo/experimental/src used as include directory in directory /home/inkrepo/experimental/src/2geom used as include directory in directory /home/inkrepo/experimental/src/libavoid used as include directory in directory /home/inkrepo/experimental/src/libcola used as include directory in directory /home/inkrepo/experimental/src/libcroco used as include directory in directory /home/inkrepo/experimental/src/libgdl used as include directory in directory /home/inkrepo/experimental/src/libuemf used as include directory in directory /home/inkrepo/experimental/src/libvpsc used as include directory in directory /home/inkrepo/experimental/src/livarot used as include directory in directory /home/inkrepo/experimental/src/libnrtype used as include directory in directory /home/inkrepo/experimental/src/libdepixelize -- Configuring incomplete, errors occurred! See also "/home/inkrepo/experimental/CMakeFiles/CMakeOutput.log". See also "/home/inkrepo/experimental/CMakeFiles/CMakeError.log". Just to prove CMake wrong about OpenMP and ImageMagick, I then did this: liam@...3128...:/home/inkrepo/experimental$ cd .. liam@...3128...:/home/inkrepo$ cat > openmp-test.cpp #include <omp.h> #include <stdio.h> int main() { #pragma omp parallel printf("Hello from thread %d, nthreads %d\n", omp_get_thread_num(), omp_get_num_threads()); }^D liam@...3128...:/home/inkrepo$ g++ -fopenmp openmp-test.cpp -o a.out liam@...3128...:/home/inkrepo$ ./a.out Hello from thread 3, nthreads 4 Hello from thread 0, nthreads 4 Hello from thread 2, nthreads 4 Hello from thread 1, nthreads 4 liam@...3128...:/home/inkrepo$ ls /usr/include/GraphicsMagick magick Magick++ Magick++.h wand liam@...3128...:/home/inkrepo$ ls /usr/include/magick analyze.h blob.h color_lookup.h common.h confirm_access.h deprecate.h enhance.h gem.h list.h magick.h monitor.h pixel_cache.h quantize.h resize.h statistics.h transform.h api.h cdl.h colormap.h compare.h constitute.h describe.h error.h gradient.h log.h magick_types.h montage.h pixel_iterator.h random.h resource.h symbols.h type.h attribute.h channel.h colorspace.h composite.h decorate.h draw.h forward.h hclut.h magic.h memory.h operator.h plasma.h registry.h shear.h texture.h utility.h average.h color.h command.h compress.h delegate.h effect.h fx.h image.h magick_config.h module.h paint.h profile.h render.h signature.h timer.h version.h What I'm not getting here is why CMake requires libmagickcore-dev to be installed — on the same system, with the same installed packages, ./configure with no parameters passed says this: Use gnome-vfs: yes Use openoffice files: yes Use relocation support: no Enable LittleCms: yes Enable DBUS: no Enable Poppler-Cairo: yes ImageMagick Magick++: yes Libwpg: yes Libvisio: yes Libcdr: no Doing Local Install: no After installing libmagickcore-dev, I ran CMake again and it "worked". I then ran make -k (and got the expected errors with poppler), but then this error about missing Magick.h. [ 20%] Building CXX object src/CMakeFiles/inkscape.dir/extension/internal/bitmap/blur.cpp.o /home/inkrepo/experimental/src/extension/internal/bitmap/blur.cpp:13:10: fatal error: 'Magick++.h' file not found #include <Magick++.h> ^ 1 error generated. *TL;DR *how do we get CMake to properly recognize OpenMP support, recognize the correct Magick, and supply the correct headers?

1 0

GSoC blurb for website
by Bryce Harrington 06 Jun '14

06 Jun '14

Now that GSoC is under way, it would be nice to replace the blurb on our homepage with a list of what projects are under way (with links to status if possible?) Bryce

3 3

Tile View widget
by Tomasz Boczkowski 04 Jun '14

04 Jun '14

Hi! I'd like to share the first screenshots of the tile view widget. It displays data in form of rectangular tiles divided into categories. It will be used in pattern selection dialogs, swatches, glyphs and symbols. The pictures are attached to this e-mail. Code is available at lp:~penginsbacon/+junk/tile-view/ Regards, Tomasz

1 0

Frost for 0.91
by Bryce Harrington 04 Jun '14

04 Jun '14

The release process is ready to now move to the Frost phase. 1. Open development. √ Triage and prioritize bugs report this year √ Itemize regression bugs found since last release 2. Chill. √ Development focuses on wrapping up √ Disable features that aren't finished √ Identify 'make distcheck' issues √ Identify any critical OSX/Win32 packaging issues √ Identify remaining writing needed for Release Notes. √ Regressions Bug Hunt: 500 points √ Update tutorials and other docs 3. Frost. √ Experimental Branch is forked √ Mainline Branch focuses on stabilization √ Only production-ready code committed to Mainline Post inkscape-0.91-pre0.tar.gz Finalize any major changes to platform packaging Release Notes should be >90% filled in. Inkscape must pass >90% of 'make distcheck' Start an About Screen contest General Bug Hunt: 1500 points Post additional inkscape-0.91-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases Mainline Branch =============== During the Frost period, developers should not commit changes to mainline unless the change improves the overall stability of Inkscape or is needed for packaging or to fix distcheck issues. Use your judgment as to what is "safe". If you're unsure, email me or Josh before committing and we'll make case-by-case decisions. As a general rule of thumb, if your commit doesn't specify a LP bug #, then it should probably be signed off on by josh or I. Experimental Branch =================== The Experimental Branch is now forked. You can check it out via: bzr branch lp:inkscape/experimental This is an official (but temporary) branch, for freely merging all development work. Please treat it as you would mainline when we're not in release, and strive to keep it buildable and usable. In particular, all merges of GSoC branches and other sponsored development work should target this experimental branch instead of mainline. Bug reports will be accepted for the experimental branch. These bug reports will be EOL'd when the experimental branch goes EOL. About Screen Contest ==================== Josh, can you and Ryan work on organizing this? This contest will need to be completed before we enter Freeze. Make Distcheck ============== Last I checked we had some distcheck issues, which will need to be resolved before we release. Basically just run `make distcheck` and work on sorting out the errors and warnings that print out. Bug Hunt ======== This time around, any bug filed against Inkscape is fair game. I'll be posting stats on Mondays. This next Monday I'll explain this in more detail. I'll start the count as of May 5th. Packaging ========= If you are working on packaging improvements, please continue to do so, with the goal of having it all in working order by the time Frost is over (probably several weeks from now). Bryce

2 2

SPPattern class refactorization.
by Tomasz Boczkowski 03 Jun '14

03 Jun '14

Hi! Tavmjonh Bah has suggested me to contact you and consult SPPaintServer class refactoring I would like to do. Currently SPPaintServer contains pattern_new method. Since it directly handles rendering and uses cairo, I think it could be moved outside of SP tree. My idea is to implement paint server drawing routines in a parallel hierarchy of classes belonging to New Renderer. Image [1] contains the class diagram. Common base for them would be NRPaintServer, containing pure virtual method pattern_new. Concrete NRPaintServer derivatives would contain a reference to corresponding SPTree items and use it while rendering. To choose an appropriate NRPaintServer for given SPPaintServer I thought about a factory method in NRPaintServer class. Example interfaces and their usage are shown at [2] The tricky part can be the implementation of NRPaintServer::create method. I have thought about two solutions: a) using a battery of dynamic_cast if statements like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { SPPattern* pattern = dynamic_cast<SPPattern*>ps; if (pattern != 0) { return new NRPattern(&pattern); } //and so on for gradients } b) using double-dispatch strategy. There would be an .cpp file internal class NRPaintServerFactory. class NRPaintServerFactory { public: virtual NRPaintServer* create(SPPaintServer*); virtual NRPaintServer* create(SPLinearGradient*); virtual NRPaintServer* create(SPRadialGradient*); //and so on } And NRPaintServer::create implementation would look like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { static NRPaintServerFactory *factory = new NRPaintServerFactory; return factory->create(ps); } What are your thoughts about this solution? [1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg [2]http://pastebin.com/h9AcrusW Regards, Tomasz

3 2

Making inkscape usable in valgrind grumble
by mathog 03 Jun '14

03 Jun '14

Hi all, In order to find memory leaks, some types of access violations, and the use of uninitialized variables I depend on valgrind. The problem is that valgrind is barely usable with Inkscape. The output on even the most minimal session (open, type a few letters, format them, close) runs to just under 500K lines and takes 5 minutes to complete. Some of this may be because garbage collection must be turned off in order to use valgrind. That is: export _INKSCAPE_GC=disable; valgrind .... src/inkscape There is no choice in that though, because if it is not done valgrind crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current Trunk). There is a libgc.supp in the top of the distribution, but it cannot be used on my system, since it does not suppress valgrind's crash when it tries to run inkscape with GC enabled. Here is the damage seen on a normal exit for a minimal run: ==16527== LEAK SUMMARY: ==16527== definitely lost: 567,697 bytes in 17,670 blocks ==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks ==16527== possibly lost: 21,940,610 bytes in 282,461 blocks ==16527== still reachable: 21,470,100 bytes in 360,304 blocks What can be done so that Inkscape makes a better effort at cleaning up its enormous memory tangle when it exits while running in valgrind? Some of the memory Inksape allocates is cleaned up, but it seems like a very high percentage of memory allocations are tacked into this complex memory structure, and inside valgrind the whole ball of yarn is just dropped on the floor when the program reaches the final exit(), rather than being unwound in an orderly fashion. (In theory GC may be cleaning this up better, but I'm not sure how we can really know, since valgrind cannot tell us.) Could somebody who understands these parts of Inkscape PLEASE clean up this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will unwind its memory structures before exiting? At the very least we will learn after this unwinding what memory is still left, and that will be the result of existing bugs in the code. Once we obtain a baseline inkscape that is usable once again in valgrind, we can reasonably expect that by using valgrind developers will be able to catch the memory problems they may introduce. Sadly that is far from true now, what with so many thousands of lines of background noise in the log files to slog through. Admittedly some of the lines in valgrind's log file do come from valgrind issues, but the ones I know about can be removed with: cat >wcslen_sse2.supp <<EOD { wcslen1 Memcheck:Addr8 fun:__wcslen_sse2 fun:* } { wcslen2 Memcheck:Cond fun:__wcslen_sse2 fun:* } { iffyinflate Memcheck:Cond fun:inflateReset2 fun:inflateInit2_ obj:* } EOD valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --log-file=/tmp/vgfi.log src/inkscape which improves the output to: --16527-- used_suppression: 208319 wcslen1 --16527-- used_suppression: 142 wcslen2 --16527-- used_suppression: 330 iffyinflate ==16527== ==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed: 208791 from 656) I understand that there may be other problems in some libraries which are called, but from the contents of the log file it looks like the majority of the loose ends were directly created in Inkscape. (And we can use valgrind suppression files, as above, to silence the unfixable library problems.) Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 3

Win64: feature complete
by Johan Engelen 03 Jun '14

03 Jun '14

Hi all, A quick note to let you know that aspell is now added to devlibs64, so that the 64bit version of Inkscape on Windows is now feature complete (i.e. same features as 32bit version) Jay! Johan

3 3

Method to duplicate a SPDocument?
by mathog 01 Jun '14

01 Jun '14

If there is an existing method for making a copy of an SPDocument, what is it called? Resolving bug 1318657, without introducing other problems, seems to require that the clipboard be replicated, and all actions occur on the replica, which is then thrown away. See comments 8 and 9 https://bugs.launchpad.net/inkscape/+bug/1318657 Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

Removal of -inkscape-font-specification ?
by Tavmjong Bah 01 Jun '14

01 Jun '14

Hi, I would like to propose the removal of the Inkscape specific -inkscape-font-specification property. This property was added in 2007 in an attempt to allow Inkscape to handle more font faces for a given font family than allowed by CSS.[1] It relied on Pango being changed to support this. In the intervening seven years, Pango has not changed nor does it seem likely it ever will. There doesn't appear to really be a need to expand on what CSS does already (and any SVG files that would use such a feature would not be viewable correctly in browsers). Inkscape (trunk) already supports, for example, all nine font faces of DejaVu Sans. Support for the font-variant features of CSS Fonts Module Level 3[2] would allow access to variants within a single font file which seems to satisfy the need that -inkscape-font-specification was meant to address. Font factories already have moved to put variants inside a single font file (vs. keeping them in separate files). See for example the bug (from 2004) about Adobe Caslon[3] with the long list of variants and the current OTF files from Adobe where the Small Caps, Alternative, and Swash variants are included in the regular files.[4] At the moment, -inkscape-font-specification duplicates the information already stored in other font related properties. There is a cost in this duplication, not only in increased file size but also in code maintenance. Keeping -inkscape-font-specification matching the other font properties is a source of bugs. It is currently making proper quoting of font-family names in font-fallback lists more difficult to fix. The actual changes needed to remove -inkscape-font-specification are straightforward and effect a few lines in about seven or eight files. No functionality would be lost as the property is completely redundant with the other font related properties. Tav [1] https://bugs.launchpad.net/inkscape/+bug/169973 [2] http://www.w3.org/TR/css3-fonts/#font-variant-prop [3] https://bugs.launchpad.net/inkscape/+bug/165521 [4] http://www.myfonts.com/fonts/adobe/caslon/buy.html

2 2