- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Rejuvenated build system for Mac OS X
by frizzlefry 19 Jun '14

19 Jun '14

Yes, the osxmenu branch is looking really fantastic. I believe though that those builds are hosted on su_v’s personal drobox account, and considering the amount of traffic this thread has been getting (it’s over 10k views now), it may be better to share them as torrents or mirror them somewhere else so su_v’s account doesn’t get hammered. On Apr 18, 2014, at 5:09 AM, duvrai [via Inkscape] <ml-node+s13n4970261h31@...2730...> wrote: > OK, I just found out about the new development on native Inkscape for Mac. > You can even download the latest unstable builds! > It's all here: > https://code.launchpad.net/~suv-lp/inkscape/osxmenu > > If you reply to this email, your message will be added to the discussion below: > http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of… > To unsubscribe from Mac OS X Mountain Lion x86_64 packaging of 0.48.4, click here. > NAML -- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 7

Re: [Inkscape-devel] patch: merge pdf import via poppler-cairo into native importer
by mathog 17 Jun '14

17 Jun '14

On 17-Jun-2014 11:55, Josh Andler wrote: > The handful of random files I had around here as well as a couple I > found > in the tracker are importing the glyphs as outlines/symbols... here are > a > couple examples: > https://bugs.launchpad.net/inkscape/+bug/429709/+attachment/718312/+files/%… > from https://bugs.launchpad.net/inkscape/+bug/429709 Ah, I see now what you are talking about. After poppler import defs is full of symbols like this: <symbol overflow="visible" id="glyph12-48"> <path style="stroke:none;" d="M 2.765625 (PATH EDITED OUT) Z " id="path4079" /> </symbol> and they are placed in the drawing with <g style="fill:rgb(0%,0%,0%);fill-opacity:1;" id="g10226"> <use xlink:href="#glyph12-48" x="183.553346" y="712.58976" id="use10228" /> </g> The original PDF did have selectable text when opened in a PDF viewer, but after poppler import into Inkscape all of the text has been replaced with graphic draws. Looks like poppler import is essentially treating everything as a draw operation, and it has no concept of <text> or <tspan>. The resulting SVG representation would not be easy to invert since the glyph IDs provide no clue as to the original font or unicode value. The part of the id before the dash is probably correlated with fonts, as in glyph1 might be "Arial", glyph2 "Courier", and so forth, but the part after is just numbered sequentially for each "glyph*" variant. Whoever is working on this might have a look at the code for "pdftotext", which comes with poppler. If that program uses the same import code it will show at least one way to retain text as text. (Or it might be completely separate from poppler's usual import and not be of any use at all. I have never looked at it.) > > https://bugs.launchpad.net/inkscape/+bug/275655/+attachment/362795/+files/m… > from https://bugs.launchpad.net/inkscape/+bug/275655 That one is odd, the text doesn't import properly in any mode on the Inkscape versions I tried, and it is also lost going into LibreOffice draw. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Re: [Inkscape-devel] patch: merge pdf import via poppler-cairo into native importer
by mathog 17 Jun '14

17 Jun '14

On 17-Jun-2014 10:47, Josh Andler wrote: > With the poppler-based import it is converting text to paths (or > symbols > from what I saw), but it still leaves the "import text as text" active > and > looking as if it will be how it functions. Is not importing the text as > text via Poppler a bug or what we should expect? Please post a link to an example (any PDF somewhere on the web) and describe the region you are talking about. PDFs have a broad spectrum of how text is encoded and without seeing the example we can't be sure where the issue is. These PDFs all look the same on the screen, but... The best case encodes each letter as its own glyph, and the encoding matches up with unicode. These are searchable with text strings in PDF viewers. Not quite so good, the PDF merges pairs of letters like "fi" into one glyph. This looks good as a graphic but causes hiccups when it hits any text processing code. These are mostly searchable, but (in this example) "file" would not be found, even when the word is staring the user in the face on the screen. Compensating is possible in special cases if there is a table of the common instances of this, and the import code splits out the merged glyphs. Really bad, PDF embeds glyphs and assigns arbitrary codes for each glyph, so that there is no correspondence whatsoever between the encoding and UTF or ASCII. These cannot be searched and will be imported as gibberish. Miserable to straighten out, but in theory it can be done by first searching each embeded glyph from the PDF against the corresponding font (assuming that can be identified), to make a table that back translates to unicode. Impossible - PDF converts text to graphic draws and there are no explicit glyphs whatsoever. This normally only shows up if the exporting program has told the program generating the PDF to do this. It might happen without the user being aware of it if the export code passes through a stage where it is forced to bitmap text in order to satisfy some special effect the program uses that cannot be represented in PDF (or in some cases in Postscript, if the PDF driver goes through the usual Windows Postscript driver.) For instance, if the transparency of the text is 0.001 (instead of 0.0) many postscript drivers are going to bitmap that text to satisfy the required transparency. The end user may not be aware that transparency is not 0, since on screen the two cases are indistinguishable. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

patch: merge pdf import via poppler-cairo into native importer
by the Adib 17 Jun '14

17 Jun '14

Hello, as already discussed here is a patch that moves the pdf poppler-cairo importer into the native pdf importer. Thus it obsoletes the current pdf-input-cairo importer and removes from the source three. If nobody complains I will go ahead and commit within the next days. Regards, Adib. --

5 13

Another video done today for BSpline feature
by Jabiertxo Arraiza Cenoz 15 Jun '14

15 Jun '14

Hi to all! Another video with bspline feature. https://www.youtube.com/watch?v=V7qYoNkK53k Regards.

1 0

New mounted video for SpiroLive feature
by Jabiertxo Arraiza Cenoz 15 Jun '14

15 Jun '14

Hi to all! I finish my first "a bit producced" video [1] about SpiroLive feature in inkscape. I want to do the same whith all others features i develop... For the moment in the video page i put a share of all sources i use to develop the video. Thanks to Martin, Gez and Gabo for his gratefoul offer to make off-voice, maybe in futures videos i ask to them but while(is enought easy) i could work whith videos and youtube notes... The music is far away from the video, like usual and want. Thanks for your 5 minutes of your live. Jabier. [1] https://www.youtube.com/watch?v=bFakiI5f0-Y

2 2

Google Summer of Code Reunion 2014
by Josh Andler 14 Jun '14

14 Jun '14

Hey All, This email concerns current and past participants of Summer of Code who have worked with Inkscape. If you have been or currently are a mentor, admin, or student with the Inkscape project for GSoC (and did not "fail") you are eligible to attend this year's Google Summer of Code Reunion at Google HQ in Mountain View, CA, USA this October. If you have successfully participated with us for GSoC in any of those three roles and you have an interest in attending, please read more here: https://sites.google.com/site/gsocmentorsummitstudentreunion/home As usual, Google will be providing funding (up to $1100 per person) for two people from our project to attend. They will also be having a lottery for other people to be able to attend (no guarantees that anyone who enters from our project will be selected), however, they will not be providing any funding for those attendees. The board is currently working on figuring out to what extent we would be interested in funding this ourselves, if any. If you are interested in attending, please respond right away as we need to solidify plans much earlier this year than in the past. If you have any questions, please don't hesitate to ask. Cheers, Josh

3 2

VALS Semester of Code
by Alexandre Prokoudine 14 Jun '14

14 Jun '14

Hi, Someone on #krita brought this to my attention yetserday: http://osswatch.jiscinvolve.org/wp/2014/05/23/vals-semester-of-code-foss-pr… "The VALS Semester of Code is an upcoming project that will work with universities andFOSS communities to give students real-world experience working in software projects. Unlike Google Summer of Code, Semester of Code students will be participating for academic credit as part of their degree courses, and we hope that after completion of their project will go on to be effective contributors to the FOSS community. The VALS initiative is a partership of European universities and SMEs who have been working for several months to plan the pilot of Semester of Code, which will run during the next academic year. We have now reached the stage where we are signing up FOSS projects who are willing to provide mentored projects of students. We have already seen interest from smaller, single-company projects to larger software foundations, and would like to see more. If you are part of a FOSS project, large or small, that would be willing to provide one or more mentored projects, we’d love to talk to you about joining Semester of Code. In return, you’ll get an enthusiastic student providing a valuable contribution to your project. The VALS team will be on hand throughout the project to answer any questions and help unblock communication issues between mentors, students and academic supervisors." Opinions? Alex

4 4

Notes from LGM Inkscape Meeting
by unknown＠example.com 14 Jun '14

14 Jun '14

Hi all, We had a very good meeting this morning. Nine (9!) Inkscapers were present (partially thanks to the Inkscape development fund). Here is a list of those present: Martin Owen/doctormo (barcode extension, Python, C++) Joakim Verona (artwork, Inkscape with emacs, d-bus, interest in embedded Inkscape) Krzysztof Kosiński (Clipboard, Cairo renderer, boolean path operations) Gémy Cédric/pygmee (extensions, Python, documentations) Sirko Kemter (LGM Host, Inkscape trainer) Elisa de Castro Guerra (documentation, translations) Ryan Lerch (Redhat user) the Adib (translation, Cairo, interest in PDF output) Myself Here are some notes I took from the session merged with some notes from Elisa (thanks!). We covered a lot of stuff. Let me appoligize to those present if I get some details mixed up. 1. Community Development The Inkscape community appears to be quite weak compared to other projects. We discussed a variety of reasons for this and possible solutions. * The community appears to be quite fragmented due to multiple websites for code, bug-tracker, mailing lists, forums, etc. We should consolidate where possible. There could be better linkage between sites. The Inkscape website still needs to be expanded. For example, there is no page for translators (already fixed since our meeting, thanks Elisa and Martin!). Also, we need make sure that feature requests in the Inkscape forums get aggregated to the developers email list. Martin will try to find someone to volunteer to act as liaison. * There appears to be a lack of direction. The Inkscape board is, by design, limited to controlling Inkscape's donations and trademark. Having some kind of steering committee might be beneficial. * There is a lack of visible momentum in the project, exasperated by the long time between current releases. (We desperately NEED to get 0.91 out - as well as 0.48.5. People need to see progress.) More news articles are needed (with rapid translation). * Paid developer: Synfig hired a developer who is now paid month-to-month by crowd-funding. This has actually stimulated additional developer contributions. People see progress being made and are more likely to make their own code contributions. There are weekly updates by the developer where people see the progress being made. (This is in contrast to the prevailing view inside the Inkscape community where paid development might threaten further contributions by non-paid developers.) Blender uses a subscription system. Many communities use a voting process to select the direction of paid development. We do need to be careful, as Scribus had a bad experience with a paid developer disappearing without delivering promised code. http://libregraphicsworld.org/blog/entry/crowdfunding-for-sustainability-sy… * Extensions is a place where people can easily make contributions. We need a web page with links to contributed extensions (or host them ourselves). (BTW, Blender had 8 part-time developers but still has a very active community of people contributing extensions.) 2. Paid developer We discussed what we would want a developer to do if one were hired. Ideas were: * Animation (high profile, improve sense of forward momentum). * PDF Export (same as above). * Plug-in structure (make it easier to contribute). * Code clean-up and documentation (make it easier to contribute). * Release (get timely releases out). * Testing 3. Website Translations Several problems were identified with translating the website. Translated news is being shown twice, once in the translated language and once in English. Martin and Adib will look into fixing this (some python coding). Also, translators are not notified of news updates. Martin will assemble a list of translators and set up a "cron" job to monitor changes to the website and then notify translators when changes are detected. 4. Technical discussions: * 0.91 release: We need to get this out, even if there are a few remaining bugs. Adib will help with Windows builds. There is great demand for a GTK3 OSX build. It seems that the only hold-up is redoing the rulers as GTK3 dropped the ruler widget. Gimp has the same problem. * Testing: We need better automated testing in both rendering and in unit-tests. cxxtests is awkward to use (and nobody seems to look at it, their are many tests failing now). * Patch reviews: We need to be quicker in reviewing patches or we risk losing new devolopers. We might need to revisit our very easy access to code check-in rights. A person writing Python extensions might not be as proficient with C++. * PDF Export: We discussed various strategies for improving our export to PDF, especially focusing on CMYK. Krzysztof has some ideas for achieving this. After our meeting, we had further discussions with people from Scribus on this topic. This topic is also coupled into possibly supporting other rendering methods (e.g. GEGL). There are a couple possible solutions. One is to extend Cairo to handle color profiles. This might not be so hard as we could write out RGB but include a color profile to hand RGB to CMYK conversion. One problem is that Cairo doesn't support the color-depth we would like. The second is to write our own PDF exporter. While Scibus's PDF export code is tightly coupled to the rest of Scribus, it can serve as a good model of what we need to do. The current "recommended" way of getting good PDF CMYK files is to pass Inkscape's SVG through Scribus. This is problematic as SVG support in Scribus is behind Inkscape's. Filters are not supported in Scribus. Adib will look in to possible filter support in Scribus. * Export: Our export mechanisms needs to be unified, probably with a "visitor's" model. * Filters: Needs to be reworked to follow the model of other objects. (There are hacks needed now to get the rendering done correctly.) * Multipage SVG: We discussed ways to use groups (layers) to handle multipage SVGs. The layer dialog might be modified with some added Inkscape name-space attributes to have groups of layers of which selecting one will hide the others in the group. (This would make editing JessyInk presentations much easier!) Martin has volunteered to put a plan together. * Remove need for "id" attributes. (Krzysztofv has an idea on this.) * Excessive signaling. Why does dragging a gradient handle cause closed dialogs to call style handling code? * Redhat/Gnome/Fedora had a series of requests already forwarded to the mailing list. * BZR migration: BZR is no longer under development.

5 6

Looking for reviewer
by Jabiertxo Arraiza Cenoz 13 Jun '14

13 Jun '14

Hi to all, Im searching for a reviewer for a short diff branch [1] https://code.launchpad.net/~inkscape.dev/inkscape/lastApplied Anybody want to do? Regards, Jabier.

2 2

GSOC status report - Better support for SVG paints
by Tomasz Boczkowski 13 Jun '14

13 Jun '14

Hi! GSOC 2014 program started a week ago. I would like to describe, what I have done since then in my project. The branch, I'm doing my development in is lp:inkscape/~penginsbacon/ inkscape/svg-paints-support. Week 1: 1) The main objective was to refactor c-style UI widgets to c++ and gtkmm. I managed to fully port SPColorSlider. It is now called Inkscape::UI::Widget::ColorSlider. The class works with both GTK2 and GTK3 libraries. Sadly, this partial task took me longer than I expected. Understanding gobject object model was quite difficult. 2) The topic of refactoring ColorSelector and related classes is being actively discussed with Jon A. Cruz at the mailing list. He mentioned possible problems with Gtkmm widgets that I was not aware of before. 3) Simple changes to SPPattern class are in progress. They consist in: a) moving c-like functions to class methods b) getting rid of GSList c) replacing gchar* by Glib::ustring d) converting *_set fields from guint to bool e) converting giuint fields to enums. Tomasz

5 7

FYI - revision 13417 eliminates routine duplication of gradients in list
by mathog 11 Jun '14

11 Jun '14

For a while now we have been working on eliminating duplications of swatches and gradients when these are imported or copy/pasted from window to window. While working on bug #1318657 I put in a change that also eliminates duplications of most gradients shown in fill/stroke when they are cut and paste in the same window. These changes were committed to trunk at revision 13417. I think the new behavior make sense but it is certainly going to look strange if you are accustomed to a huge number of gradients piling up in that list. For a better description see https://bugs.launchpad.net/inkscape/+bug/1318657/comments/12 and also post 14 there. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Re: [Inkscape-devel] Some memory leaks in replaceArgs function ( main.cpp )
by Krzysztof Kosiński 10 Jun '14

10 Jun '14

There is no point in rewriting this code; it should be ported to GOption, which recently added functions required to properly support Windows. Regards, Krzysztof From: Johan Engelen Sent: 2014-06-10 19:51 To: inkscape-devel(a)lists.sourceforge.net; neandertalspeople@...400... Subject: Re: [Inkscape-devel] Some memory leaks in replaceArgs function ( main.cpp ) Actually, all your changes are incorrect. Your patch is deleting memory which the code still holds pointers to. The code is quite bad indeed, but should be fixed differently. At the end of the method, all memory that the parser array has pointers to should be freed. The problem is that these pointers point to memory blocks that have been allocated differently, or point to memory locations within an allocated array. It's a mess. The whole function should be rewritten. Please create a bug report for it. regards, Johan On 10-6-2014 19:35, Johan Engelen wrote: > On 10-6-2014 17:29, Guiu Rocafort wrote: >> Hi ! >> >> Making a simple check to see if all the new operators are freed using >> delete i found that there are some memory leaks in main.cpp, in the >> function replaceArgs ( which only affects the windows version of >> inkscape ). >> >> I've added the missing delete operators and those memory leaks should >> be fixed. >> I attach the .patch file, if you want me to fill a bug report and then >> submit the patch instead please tell me. > Did you test your patch? While you are right that there are some > memleaks, there are less than you think there are :) (e.g. your > "delete[] block;" on line 1984 is wrong) > > I'll rework and commit it. > > regards, > Johan > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 1

Some memory leaks in replaceArgs function ( main.cpp )
by Guiu Rocafort 10 Jun '14

10 Jun '14

Hi ! Making a simple check to see if all the new operators are freed using delete i found that there are some memory leaks in main.cpp, in the function replaceArgs ( which only affects the windows version of inkscape ). I've added the missing delete operators and those memory leaks should be fixed. I attach the .patch file, if you want me to fill a bug report and then submit the patch instead please tell me. Guiu Rocafort -- *Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html <http://www.gnu.org/philosophy/no-word-attachments.html>*

2 2

Somebody please test patch for bug 1318657
by mathog 10 Jun '14

10 Jun '14

If one of you gets a chance, please test the patch for bug 1318657 (in post 10) https://bugs.launchpad.net/inkscape/+bug/1318657 and see if you can break it. I didn't want to commit that change until another developer had a look at it. (Because this section of code is easy to break, and we keep running into cases that are not handled, like the present bug, which is the result of an incoming document containing two copies of a gradient/swatch with different names.) Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Last call for 0.48.5
by Josh Andler 09 Jun '14

09 Jun '14

Hey all, We have some license compliance issues which have been fixed in the 0.48.x branch which is overdue for should release anyway. I don't recall seeing objections the last time releasing 0.48.5 was brought up (but could have missed something). If there are no issues left unmentioned or unresolved prior to next Sunday, May 25, we will move forward with releasing it. Given that our focus is really on moving forward with 0.91, please speak up as this is likely to be the last release in the 0.48 series. Cheers, Josh

5 8

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