- Inkscape Devel - Inkscape Mailman

Interested in GSoC 2013
by Catalin Ramascanu 27 Feb '13

27 Feb '13

Hello! My name is Catalin Ramascanu and I am interested in joining Inkscape for this years edition of Google Summer of Code. I am a second year student at the Faculty of Automatics and Computer Science from Bucharest, Romania and I have been using Inkscape for about a month , because currently I am working on a game application for Windows 8.I am really enjoying working with this software and I would really like to make an important contribution to this project. I have read the Inkscape wiki page regarding GSoC 2013 and I am interested in the internal work and performance improvements , specifically the startup time and initialization performance. I have also noticed the slow startup time while working with Inkscape and if it were to be improved , that would be very great. I would like know more information regarding this proposal , why does it take that long to startup and what could the problem be. I am also curios regarding the proposal "Continue C++ification" , could I receive some more information about this idea? I am very familiar with the following programming languages: C , Java , Javascript and can adapt very fast to C++. Thank you very much for your time!

6 5

Font-family drop-down menu change.
by Tavmjong Bah 25 Feb '13

25 Feb '13

Hi, I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name. Let me know what you think of this. Tav

11 40

Handling deprecated GNOME symbols
by Alex Valavanis 23 Feb '13

23 Feb '13

Hi All, A while ago I added checks in configure.ac to ensure that deprecated library symbols don't get used. However, this approach is probably *too strict* to be included in a stable release... for example, it will cause build-failures that are not "our fault" when the following conditions occur: * inkscape depends on library-A and library-B * inkscape disables deprecated symbols from library-B * library-A depends on deprecated symbols in library-B. This situation is currently causing build failures on Ubuntu Raring because it provides Glibmm 2.34.1, which depends on newly-deprecated symbols in glib 2.35.7. So... we need to consider our approach. Options: 1. Unconditionally allow all deprecated symbols in all libraries. (i.e., remove all the checks I introduced in configure.ac). This would prevent breakage when new deprecations are introduced... but would potentially mean nightmarish migration tasks in the future (as with the GTK+ 3 migration)! 2. Keep the deprecation checks for all libraries: We'd then need to keep fire-fighting the build breakages in distros. Not a good idea in my opinion! 3. Keep the deprecation checks only for high-level libraries: i.e., Gtkmm depends on gtk+ and glib, so we can guard against using deprecated gtkmm stuff but not the others. 4. Add a configuration flag for developers' use (something like "--enable-strict-build") that introduces the deprecation checks. My preferred option... but would people actually use it? 5. Something else? Any thoughts? AV

2 2

Why is this blowing up?
by mathog 22 Feb '13

22 Feb '13

Can somebody tell me what is wrong with this code (fragments shown below). It throws some sort of exception which Inkscape catches when it gets down to (*result).back().append(ls); However, there is no problem doing output.back().append(ls); // output is what result was named in the caller in pathv_to_linear, where "output" was created. It is only a problem when the pathvector has been passed into the second (recursive) function. Geom::PathVector pathv_to_linear( Geom::PathVector const &pathv, double maxdisp) { Geom::PathVector output; Geom::PathVector tmppath = pathv_to_linear_and_cubic_beziers(pathv); for (Geom::PathVector::const_iterator pit = tmppath.begin(); pit != tmppath.end(); ++pit) { output.push_back( Geom::Path() ); output.back().start( pit->initialPoint() ); output.back().close( pit->closed() ); for (Geom::Path::const_iterator cit = pit->begin(); cit != pit->end_open(); ++cit) { ... double xe,ye; int pset = 0; // set to 1 once a last point has been set recursive_bezier4( A[X], A[Y], B[X], B[Y], C[X], C[Y], D[X], D[Y], &xe, &ye, &pset, &output, 0); ... } void recursive_bezier4(const double x1, const double y1, const double x2, const double y2, const double x3, const double y3, const double x4, const double y4, double *xe, double *ye, // last point added, if any int *pset, // 1 if value for xe,ye have been set Geom::PathVector *result, int level) { ... r1=Geom::Point(x23,y23); Geom::LineSegment ls(r0, r1); (*result).back().append(ls); // <---- Blows up here ... recursive_bezier4(x1, y1, x12, y12, x123, y123, x1234, y1234, xe, ye, pset, result, level+1); recursive_bezier4(x1234, y1234, x234, y234, x34, y34, x4, y4, xe, ye, pset, result, level+1); } ************************************** I tried putting this r0=Geom::Point(0.0,0.0); r1=Geom::Point(1.0,1.0); Geom::LineSegment ls(r0, r1); (*result).back().append(ls); // blows up here at the top of recursive_bezier4, and it blew up in the first call, so it isn't losing the pointer in the recursion, it is invalid from the first call. However, there are no compiler errors or warnings. I also tried it this way: //in pathv_to_linear recursive_bezier4( A[X], A[Y], B[X], B[Y], C[X], C[Y], D[X], D[Y], &xe, &ye, &pset, output, 0); void recursive_bezier4(const double x1, const double y1, const double x2, const double y2, const double x3, const double y3, const double x4, const double y4, double *xe, double *ye, // last point added, if any int *pset, // 1 if value for xe,ye have been set Geom::PathVector &result, int level) { .. r0=Geom::Point(0.0,0.0); r1=Geom::Point(1.0,1.0); Geom::LineSegment ls(r0, r1); result.back().append(ls); but it had the same problem, or at least the (new) error was on the same line. When run in gdb inkscape still caught the exception, so gdb did not break at the problem. My guess is that even if gdb had caught it it would not have been very informative, just some inscrutable error at the line where I already know the problem shows up. Any ideas what might be causing this? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 2

How to enable LPE currently disabled?
by Brainless 19 Feb '13

19 Feb '13

Hello. I would like to include in a build for windows some of the LPEs currently disabled. A part from uncommenting the line 209 of the file "build.xml", do I have to do something else? I would like to enable only some of them according to what a user (druban) on Inkscapeforum (http://www.inkscapeforum.com/viewtopic.php?f=28&t=2110#p52318) told me. The list is the following: 1. Angle bisector; 2. Circle by center and radius; 3. Circle by three points (this I think could be replaced by draw from triangle or smthg like that); 4. Lattice deformation; 5. Mirror simmetry; 6. Path length; 7. Tangent to curve; 8. Text label If someone could help me, I will appreciate very much. Thanks MM -- View this message in context: http://inkscape.13.n6.nabble.com/How-to-enable-LPE-currently-disabled-tp496… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 3

Anybody going to LGM 2013 meeting in Madrid?
by Julien Deswaef 13 Feb '13

13 Feb '13

Hello everyone. First post here. Hope you all doing fine. Since I never said it out loud, here is a very big thank you for your work on Inkscape. It's my tool of choice for most of my graphic stuff. I was wondering if any of you was planning on going to the Libre Graphics Meeting in Madrid this year. http://libregraphicsmeeting.org/2013/ I'm asking this because there is a Interactivos?'13 workshop following the event and I'm looking for collaborators on a project involving Inkscape. The project is called "Design With Git" and you can read about my call for collaborators on the Medialab Prado forum. http://servidor.medialab-prado.es/~foros/punbb-1.4.1/viewtopic.php?id=32957 If you find this interesting, I would love to have your opinion and maybe have you on site working with me on this. Please note that for residents out of Madrid, Medialab-Prado will cover for the stay of a limited number of participants at the MadHostel during the dates of the celebration of the workshop. Though, unfortunately, it will not cover for your travel expenses. Looking forward for your comments and thoughts. Julien -- blog: http://p.xuv.be site: http://xuv.be

2 2

gsoc2013
by Alexandre Prokoudine 13 Feb '13

13 Feb '13

Hi, GSoC2013 is on. Are we trying to participate this year? Alexandre Prokoudine http://libregraphicsworld.org

2 3

Debugging a crash on return from graphics open()? call?
by mathog 12 Feb '13

12 Feb '13

Working on putting libUEMF's wmf support into inkscape in branch lp988601. Replicated the emf-inout/emf-print files in /src/extension/internal as wmf-inout/wmf-print, modified these to use WMF pieces instead of EMF, and cleaned up the collisions (some globals had been used originally). Got it all to compile cleanly. Problem is, it is blowing up on the "return doc" from SPDocument * Wmf::open( Inkscape::Extension::Input * /*mod*/, const gchar *uri ) { the "doc" has been created, and near as I can tell it is kosher. At least the SVG text fed in here: SPDocument *doc = SPDocument::createNewDocFromMem(d.outsvg->c_str(), strlen(d.outsvg->c_str()), TRUE); was OK (can be cut/paste into a separate SVG file, and it loads fine). The doc pointer is nonzero. Print statements work all the way down to: std::cout << "DEBUG Wmf::open post myMetaFileProc 3" <<std::endl; return doc; } Tried running it in gdb and after the crash Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. did a bt, which showed: [New Thread 0xb5f21b40 (LWP 14365)] Program received signal SIGSEGV, Segmentation fault. 0x01380110 in g_mutex_lock@...2945... () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (gdb) bt #0 0x01380110 in g_mutex_lock@...2945... () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #1 0x0139713f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #2 0x0139f2dc in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #3 0x0139f453 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #4 0x00abd2da in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 #5 0x00ab8d3b in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 #6 0x013871ec in g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #7 0x01385484 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #8 0x013970c0 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #9 0x0139f2dc in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #10 0x00000000 in ?? () Not very useful. How does one debug this sort of thing? I will try valgrind next (which is a real last resort for Inkscape, since it takes 10 minutes run that way, and there are scads of error problems reported, which tends to swamp the issue). But gdb sure wasn't very helpful! Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 3

Launchpad Inkscape Bug Team subscription
by Nicolas Dufour 12 Feb '13

12 Feb '13

Hi, As you may have noticed if your in the Launchpad Inkscape bug team, the flow of notifications has dramatically decreased recently. Instead of sending notifications whatever happens in the reports, the LP bug system limited the notifications to new and closed bug. I first thought it was due to a new LP feature, reset with new default values, but it finally seems it was changed by someone in the Inkscape administrators team. I understand there are too many notifications for developers, but bug managers need everything to appropriately triage the reports. For now, the settings have been reset with the previous values (notify everything, including comments) for the bug team (LP subscription page: https://bugs.launchpad.net/inkscape/+subscriptions). If needed, we have the possibility to subscribe the Inkscape Developers team to the bug system, with limited notifications (new and closed only, or filter based), or a new specific team if we don't want to reuse the developers team. The debate is open. Regards, -- Nicolas

1 0

Re: [Inkscape-devel] Image resampling [PATCH 0/6]
by Krzysztof Kosiński 12 Feb '13

12 Feb '13

2012/11/24 Søren Sandmann <sandmann@...2931...>: > Hi, > > Reviewing the supersampling patch here: > > http://cgit.freedesktop.org/~ajohnson/pixman/log/?h=supersampling > > I wasn't happy with either the performance and image quality, and I > realized that the whole supersampling approach just isn't going to > fly. Since I told people to do it that way, I apologize for that. The > approach advocated by Bill Spitzak in the various downsampling threads > of computing a convolution kernel up front, is the much better way to > go. To make up for being misleading, the following patches implement > comprehensive support for high-quality image scaling filters. This is extremely awesome. Regards, Krzysztof

4 6