- Inkscape Devel - Inkscape Mailman

Chill for 0.91
by Bryce Harrington 28 Dec '13

28 Dec '13

As there have been no objections so far, I'd like to move that we begin the Chill phase of the release cycle today. If there are any objections, please raise them ASAP. Otherwise, we can begin the Regression Bug Hunt starting tomorrow. Bryce On Mon, Dec 23, 2013 at 02:16:22PM -0800, Bryce Harrington wrote: > Any other comments on the plan? > > If there's no objections, then I'd like to propose we begin Chill in a > week, on Dec 28th. > > Between now and then would be a good opportunity to focus on bug triage. > In particular, it would be helpful to get all bugs assigned a priority. > > Bryce > > > On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote: > > Hi all, > > > > Josh and I have been discussing plans for the upcoming release; below > > is what we've come up with so far. This is loosely based on past 0.4x > > plans. I'll follow up this email with explanations for the major > > differences. Meanwhile, feedback would be appreciated. > > > > > > # Period Tasks Notes > > -------------------------------------------------------------------------------- > > 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 P > > Identify remaining writing needed for Release Notes. > > Regressions Bug Hunt: 500 points H > > Update tutorials and other docs > > > > 3. Frost. Experimental Branch is forked B > > Mainline Branch focuses on stabilization B > > Only production-ready code committed to Mainline B > > Post inkscape-0.91-pre0.tar.gz > > Finalize any major changes to platform packaging P > > Release Notes should be >90% filled in. > > Inkscape must pass >90% of 'make distcheck' > > Start an About Screen contest A > > General Bug Hunt: 1500 points H > > Post additional inkscape-0.91-pre*.tar.gz releases > > Packagers test creating pkgs of the -pre* releases P > > > > 4. Feature Freeze. Stable Branch is forked from Mainline B > > Regular development resumes on Mainline. B > > Avoid major refactorings on Mainline. B > > Only bug fixes committed to Stable Branch. B > > Bug fixes are cherrypicked from Mainline. B > > Inkscape must pass 'make distcheck' > > String Freeze No further string changes allowed on Stable Branch. T > > Finalize tutorials to be shipped with release > > Finalize other docs included in the release > > Finalize about screen A > > Finalize Release Notes except Known Issues > > Translators work on translations. T > > Recruit Release Wardens for Hard Freeze > > > > 5. Hard freeze. Only Release Wardens can commit to Stable Branch B > > Cherrypick bug fixes from Mainline to Stable B > > Complete any late work under advisement of Wardens > > Focus on release-critical bug fixing. > > Finalize all extensions > > Finalize codebase translations T > > Finalize Known Issues section of Release Notes > > Finalize packaging scripts > > Post additional inkscape-0.91-pre*.tar.gz releases > > > > 6. Release. Post inkscape-0.91.tar.gz > > Post packages > > Post official announcements > > Plan 0.91.1+ release(s), if needed > > > > 7. Open development. > > > > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Re: [Inkscape-devel] Proposal for release plan
by Bryce Harrington 25 Dec '13

25 Dec '13

Any other comments on the plan? If there's no objections, then I'd like to propose we begin Chill in a week, on Dec 28th. Between now and then would be a good opportunity to focus on bug triage. In particular, it would be helpful to get all bugs assigned a priority. Bryce On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote: > Hi all, > > Josh and I have been discussing plans for the upcoming release; below > is what we've come up with so far. This is loosely based on past 0.4x > plans. I'll follow up this email with explanations for the major > differences. Meanwhile, feedback would be appreciated. > > > # Period Tasks Notes > -------------------------------------------------------------------------------- > 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 P > Identify remaining writing needed for Release Notes. > Regressions Bug Hunt: 500 points H > Update tutorials and other docs > > 3. Frost. Experimental Branch is forked B > Mainline Branch focuses on stabilization B > Only production-ready code committed to Mainline B > Post inkscape-0.91-pre0.tar.gz > Finalize any major changes to platform packaging P > Release Notes should be >90% filled in. > Inkscape must pass >90% of 'make distcheck' > Start an About Screen contest A > General Bug Hunt: 1500 points H > Post additional inkscape-0.91-pre*.tar.gz releases > Packagers test creating pkgs of the -pre* releases P > > 4. Feature Freeze. Stable Branch is forked from Mainline B > Regular development resumes on Mainline. B > Avoid major refactorings on Mainline. B > Only bug fixes committed to Stable Branch. B > Bug fixes are cherrypicked from Mainline. B > Inkscape must pass 'make distcheck' > String Freeze No further string changes allowed on Stable Branch. T > Finalize tutorials to be shipped with release > Finalize other docs included in the release > Finalize about screen A > Finalize Release Notes except Known Issues > Translators work on translations. T > Recruit Release Wardens for Hard Freeze > > 5. Hard freeze. Only Release Wardens can commit to Stable Branch B > Cherrypick bug fixes from Mainline to Stable B > Complete any late work under advisement of Wardens > Focus on release-critical bug fixing. > Finalize all extensions > Finalize codebase translations T > Finalize Known Issues section of Release Notes > Finalize packaging scripts > Post additional inkscape-0.91-pre*.tar.gz releases > > 6. Release. Post inkscape-0.91.tar.gz > Post packages > Post official announcements > Plan 0.91.1+ release(s), if needed > > 7. Open development. > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 3

RSVG / Inkscape render differently
by Campbell Barton 24 Dec '13

24 Dec '13

Hi, we have some icons which are made in inkscape but render differently in RSVG, Most (all?) of the applications on Linux are using RSVG, so I was wondering if there is a good way to determine if this is some special inkscape feature or a bug/limitation in RSVG. Comparison: http://git.blender.org/gitweb/gitweb.cgi/blender.git/blob_plain/HEAD:/relea… http://git.blender.org/gitweb/gitweb.cgi/blender.git/blob_plain/HEAD:/relea… Note that RSVG seems to fail on groups that have alpha masking. -- - Campbell

5 6

download page
by Jabiertxo Arraiza Cenoz 24 Dec '13

24 Dec '13

Hi to all. I made some html edit in the spanish page http://inkscape.org/es/descargas/ -top three logos- My cuestion is: Is convenient update it in english, or because not only translate work, need revision? Maybe need to roolback to previous version and update in testing... Regards, Jabier.

4 7

inkscapeforum.com submenu in website
by Jabiertxo Arraiza Cenoz 23 Dec '13

23 Dec '13

Whats the opinion to give this link in a visible way? inkscapeforum.com Regards, Jabier.

3 3

info to devel groups
by Jabiertxo Arraiza Cenoz 23 Dec '13

23 Dec '13

Hi to all. This dates make me read the past year. My first project, except some extensions, bspline&spirolive[0] date form near september of 2012. There is some contributions from this year, and want the next year could continue: * Temporary helper path re-added to live effects [1] * Multiple path parameter editing on live effects [2] * Improved perspective_path LPE [3] * Improved Laticce LPE [4] * Fix to translate shapes whith LPE applied in trunk [5] * Changes to the lpe system whith two patch to select best, this make no strange results in LPE effects in nested groups, one patch perserve shapes but the behabiour is not perfect and the other convert this to paths but work "perfect" [6] * Retain the last applied "stroke" to the pen and pencil combo box improved whith the help of Krzysztof [7] * Bend from clipboard, this applied a bend effect to the strokes whith the shape in "stroke combo". I`m not so happy with this, but ... [8] * Live effects applied to mask and clips [9] [0] https://code.launchpad.net/~inktxof/inkscape/bspline+spirolive [1] https://bugs.launchpad.net/inkscape/+bug/1246550 [2] https://bugs.launchpad.net/inkscape/+bug/609839 [3] https://bugs.launchpad.net/inkscape/+bug/1068987 [4] https://code.launchpad.net/~inktxof/inkscape/lattice2 [5] https://bugs.launchpad.net/inkscape/+bug/1247324 [6] https://bugs.launchpad.net/inkscape/+bug/1242170 [7] https://code.launchpad.net/~inktxof/inkscape/lastApplied [8] https://code.launchpad.net/~inktxof/inkscape/bendFromClipboard [9] https://bugs.launchpad.net/inkscape/+bug/1241902 Maybe i could get reviews and make "alive" some of my work. Special thanks to su_v that make a lot of this work be real with her encouragement. GoodYear by the way! Regards, Jabier.

1 0

Website tarball icons
by Jabiertxo Arraiza Cenoz 23 Dec '13

23 Dec '13

Hi to all. In the page http://inkscape.org/en/download/source/ there are two tarball icons. I think they are too big, maybe can be reduced 60-70% and change the tool box by a sigle item like a nut or a partial wrench, because there are too much detail for a icon in the, beatiful, tool box. Maybe this icons are beter at start instead the end. Regards, Jabier.

3 4

Faces of Inkscape Users
by Martin Owens 23 Dec '13

23 Dec '13

Hi Inkscapers, Did you know the new website has the ability to edit your profile and add a photo? So far and rather excitingly we have 543 registered accounts to the inkscape website and some have added their pictures: http://imagebin.org/281976 [1] I'm asking inkscape board members and other developers to upload something for themselves, a photo, a little bio if you have one. I want to make a page of "Inkscape Developers" and "Inkscape Board" to give a view of the humans behind the project but I will need more data. Edit now: http://inkscape.org/person/edit/ Thanks guys! Best Regards, Martin Owens [1] For now this page is super users only: http://inkscape.org/person/faces/ I've not finalized the view.

7 13

My login on the inkscape.org site
by Leo Jackson 22 Dec '13

22 Dec '13

Martin, Happy Holidays! I use to have access to the inkscape site to do edits, and now I reregistered with lajjr user name if you can please upgrade it so I can help on the website again. I was working on the Develop => Debugging page and anything else that is possible. Also If someone already completed that then can I get a list of tasks please? Thank You Regards, Leo Jackson

2 1

recognizing rectangles, lines, etc. in 2geom, like "isrect()"???
by mathog 21 Dec '13

21 Dec '13

This is sort of a follow up question to my previous one about circles. Is there in 2geom a set of methods along the lines of: isRect(path) isTriangle(path) isLine(path) which return true if the path has the specified geometry? I need the first one and don't want to reinvent the wheel. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 5

Proposal for release plan
by Bryce Harrington 19 Dec '13

19 Dec '13

Hi all, Josh and I have been discussing plans for the upcoming release; below is what we've come up with so far. This is loosely based on past 0.4x plans. I'll follow up this email with explanations for the major differences. Meanwhile, feedback would be appreciated. # Period Tasks Notes -------------------------------------------------------------------------------- 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 P Identify remaining writing needed for Release Notes. Regressions Bug Hunt: 500 points H Update tutorials and other docs 3. Frost. Experimental Branch is forked B Mainline Branch focuses on stabilization B Only production-ready code committed to Mainline B Post inkscape-0.91-pre0.tar.gz Finalize any major changes to platform packaging P Release Notes should be >90% filled in. Inkscape must pass >90% of 'make distcheck' Start an About Screen contest A General Bug Hunt: 1500 points H Post additional inkscape-0.91-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases P 4. Feature Freeze. Stable Branch is forked from Mainline B Regular development resumes on Mainline. B Avoid major refactorings on Mainline. B Only bug fixes committed to Stable Branch. B Bug fixes are cherrypicked from Mainline. B Inkscape must pass 'make distcheck' String Freeze No further string changes allowed on Stable Branch. T Finalize tutorials to be shipped with release Finalize other docs included in the release Finalize about screen A Finalize Release Notes except Known Issues Translators work on translations. T Recruit Release Wardens for Hard Freeze 5. Hard freeze. Only Release Wardens can commit to Stable Branch B Cherrypick bug fixes from Mainline to Stable B Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations T Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases 6. Release. Post inkscape-0.91.tar.gz Post packages Post official announcements Plan 0.91.1+ release(s), if needed 7. Open development.

4 15

Devlibs 46 too slow
by LucaDC 19 Dec '13

19 Dec '13

After updating to devlibs r46 moving objects around becomes too slow in my system and Inkscape is nearly unusable even for simple drawings. Open a new document, draw a rectangle and move it around: the lag is huge. Even changings of the cursor when hovering over it are updated with delays of 1 s or more. Moving and snapping guides (not to guides), on the other hand, is very fast. My system is a Pentium 4, 3,2 GHz, 2 Gb RAM with Windows XP SP3. Reverting to devlibs r45 (trunk 12277) gives back the previous (acceptable) response time. I know my system is old, but with r45 it's fine for all my needs. Isn't this terrible performance drop avoidable? Inkscape is already not a jaguar... Regards. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 22

Inkscape performance - two suggestions
by Paul Kallnbach 19 Dec '13

19 Dec '13

Dear list, this is my first contact to the inkscape developer community and I hope my messages is not received as being overly critical or even offending as I'm clearly talking about things I do not fully understand. You're all doing a great job on Inkscape and I l-o-v-e the upcoming 0.49 release! It is no secret that Inkscape suffers some performance issues when editing or just viewing complex svg files, especially at high zoom levels. Particularly there is a noticable lag between a user action (e.g. zooming in) and the start of the rendering process. I'm not an experienced c++ programmer nor do I know much about how Inkscape works internally but I crawled through the code, following the chain of actions Inkscape does, when its processing its user actions and it turned out that commenting out the following lines instantly removes the bespoken delay and thus greatly accelerates the responsiveness of the program for complex drawings: in drawing-item.cpp, line 586 - 589: :572 if (_cached) { if (_cache) { _cache->prepare(); #ifdef WITH_CSSBLEND set_cairo_blend_operator( ct, _blend_mode ); #endif _cache->paintFromCache(ct, carea); if (!carea) return RENDER_OK; } else { // There is no cache. This could be because caching of this item // was just turned on after the last update phase, or because // we were previously outside of the canvas. Geom::OptIntRect cl = _drawing.cacheLimit(); cl.intersectWith(_drawbox); /* if (cl) { _cache = new DrawingCache(*cl); } */ } } else { // if our caching was turned off after the last update, it was already // deleted in setCached() :593 } I don't know much about Inkscapes caching mechanisms but clearly a cache that slows down a program instead of accelerating it is broken. Furthermore this else-statement should be a rather rare exception to be called but the program behaviour indicates its called not only for every object but also every time the canvas is updated, which might indicate a more complicated issue.. I am fully aware that just commenting this out is not a solution to the problem but maybe somebody more experienced could have a look at the functions involved and come up with a more sophisticated solution? The second suggestion I wanted to make is more a design decision I'm afraid. It is about Inkscape interrupting the redraw process (see sp-canvas.cpp, around line 1967) At the moment the redraw is aborted if its not done in less than 1 microsecond, which, at least on my system, almost never happens unless I pan very slowly. The result are very ugly artefacts on the edge of the screen when the user pans/scrolls the canvas (see this screenshot for clarification: http://www.gorilla-computing.de/misc/inkscape_screenshot.jpg). Has ever been considered to increase that limit so Inkscape can actually finish the redraw more often? I experimented around a bit and a value of 100ms seems to do the job just fine - especially with the cache lag gone. And it should still be low enough to process different user input when needed. If it is not possible to hardcode that limit to a sensible value, maybe one could make it a slider in the options->render menu? Thanks for your considerations! Best, Paul

1 0

new scaling/stretching behaviour with Preserved Transforms
by alvinpenner 18 Dec '13

18 Dec '13

This is an attempt to summarize the types of scaling behaviour that can occur, and to highlight a few remaining unresolved issues. Only the behaviour of the visual bbox will be discussed. In Inkscape 0.48.4 there were two types of stretching behaviour, depending on the choice of the preference for Scale Stroke Width. The choice of the preference for Optimized/Preserved Transforms did not affect the visual appearance in Inkscape, although it did in other renderers. With the implementation of the new Cairo renderer both of these preferences now affect the visual appearance, as they should. So there are now 4 possible results. The attached file 4boxes.svg has four identical boxes in a horizontal row. After stretching vertically with the Select tool (F1) we get file 4boxes_12851.svg. The four types of stretch used here were, from left to right: scale/optimized, no scale/optimized, scale/preserved, no scale/preserved. The first three cases scale more or less as expected, the fourth case is a bit unexpected. Since the idea of a constant (apparent) stroke width is meaningless in the case of a preserved transform, what has happened here is that the geometric mean of the apparent horizontal stroke and the apparent vertical stroke has been kept constant during the stretch, which is why the stroke along the horizontal axis is so narrow. Upon looking closer, case 3, scaled/preserved, has a few minor inconsistencies: it is too narrow and there is a vertical offset. These have been addressed in rev 12852. The result is shown in the file 4boxes_12852.svg. There are two remaining issues which may be more difficult to solve. In case 4, no scale/preserved, there is a remaining vertical offset. The offset is actually more serious than it appears to be, because it is persistent, it does not go away even after performing a round trip by contracting the shape again. It appears to be related to the fact that the stretching was asymmetric. If you drag at a 45 degree angle, then there is no offset. This will be reported elsewhere as a bug. The second unresolved issue is that the appearance during the drag is not the same as the appearance after releasing the object (Bug 1258271). Hoping to raise the visibility of this behaviour because this has provoked some discussion in the past, Bug 805392, Bug 805793; and since I have no idea how to fix the remaining issues. 4boxes.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes.svg> 4boxes_12851.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12851.svg> 4boxes_12852.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12852.svg> Cheers, Alvin -- View this message in context: http://inkscape.13.x6.nabble.com/new-scaling-stretching-behaviour-with-Pres… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

possible bug?
by TimeWaster 18 Dec '13

18 Dec '13

i have the attached document: <svg [...] width="602.36218" height="336.04724" [...] viewBox="0 0 170 94.840002"> <sodipodi:namedview [...] inkscape:document-units="mm" [...] > in inkscape "custom size" is set to px, "default units" is set to mm. width and heigth are the size of the document in pixel, all other numbers are in mm. (they all have no unit specified, but i know it because of the dimensions of the drawing) shouldn't the width and height parameter be width="602.36218px" instead of width="602.36218" since the document wide unit is mm (even the viewBox is in mm)? i am using r12832 right now. i think this is related to https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed there, which i cannot confirm. and even if you say that width should always be in px, having no explicit unit given makes it harder (more obfuscated) for people to understand and parse the documents. regards, TimeWaster -- Save a printer manufacturer. Print this e-mail unless it's really necessary not to do so.

2 1

Re: [Inkscape-devel] Dealing with OS reported bugs
by Bryce Harrington 17 Dec '13

17 Dec '13

On Tue, Dec 17, 2013 at 08:30:28AM +0000, Nicolas Dufour wrote: > On Sun, Dec 15, 2013 at 07:42:49PM +0100, Kris De Gussem wrote: > >> I was wondering how to deal with bug reports automatically submitted by the > >> operating system. It is often hard to verify for these bugs how exactly one > >> could to provoke the issue but on the other hand it may be clear from the > >> backtrace that some null pointer check (or related thing) is missing). > > It's particularly difficult to deal with the Ubuntu automatic reports, > mainly because they often don't include steps to reproduce. We can try > to fix it thanks to the backtrace, but we have no certainty that it is > actually fixed without the steps. So what should we do? Close as soon > as we have committed a fix or wait until someone finds a way to > reproduce and confirm the fix works. I don't think there can be a hard and fast rule here; it's kind of a judgment call. For X.org bugs in Ubuntu, where there was a crash we didn't know how to repro but the stacktrace pointed out the flaw (a null pointer deref or whatever), I'd commit the patch and mark the bug fixed. We would only need the steps to repro and confirmation of the fix if we needed to backport the fix to a stable release. When the stacktrace didn't point out the flaw definitively, then we would indeed need to get steps to repro. If we had an idea for a patch, I'd post it to the bug report (and put a test package with the patch into a PPA), and wait on committing it to mainline until a user confirmed it. We usually only did this for crashes and lockups that were being hit by a lot of users, so even if one person was unresponsive, we could wait until another person filed a new bug, or commented on the original one. In a lot of cases the crash or hang wasn't deterministic but tended to occur periodically over N hours, so if they ran the package and used it for > 2*N hours we called it good. It's worth noting that the automatic collecting tool avoids creating new bug reports if it finds one with the same stack trace that still has an open distro task. So, being a little aggressive at closing these bugs when you suspect they're fixed is okay - the system will file a new one if it's still crashing for someone. My guess for Inkscape is that the former case is going to be more applicable. Perhaps suv has better advice on Inkscape policy here? Of course, if the codebase is frozen for a release, there'll be stricter rules, since we do want to make sure a committed fix really does fix the issue, but there'll be policy guidance given when we're at that point. By the way, the automatically generated bug reports can be controlled on the ubuntu side. We can arrange to collect some additional logs from the system at the time of the crash. (Very useful for X.org bug reports; maybe less so for Inkscape.) Also, there is a site at errors.ubuntu.com where ALL reported crashes appear, even if the user doesn't file a bug report. This site counts how many of each crash were reported for each Ubuntu release, and links to the bug report if there is one. You have to register to gain access to the detailed data (let me know if you're applying and I'll put in a good word with the ubuntu folks.) So right now, for package 0.48.4-1ubuntu3, the top crashers hit by users this past month are: Bug 1047748 (71 crashes) sp_dtw_color_profile_event Bug 1216167 (14 crashes) pathv_to_linear_and_cubic_beziers (8 crashes) sp_guideline_destroy (8 crashes) sp_ctrlpoint_set_color The interface also allows creating bug reports for crashes that don't yet have one. I created 1261918 as an example. Looks like there's a bunch of crashes that don't have bug reports yet. The detail crash report page shows a full stack trace, and a table showing other instances of the crash, what package version and ubuntu version were in use, and the date and time the crash occurred. You can also look at other examples of the stack trace, which can sometimes be handy to compare data or examine race conditions. For X.org I found this tool very helpful for prioritizing what crashers to work on, and identifying where backports of a fix to earlier stable releases would bring good bang for the buck. HTH, Bryce

1 0

Powerstroke questions
by Tom Lechner 17 Dec '13

17 Dec '13

Hi, I really love the powerstroke path effect, but some questions. 1. How accessible is the stroke information? From the file, it appears it is stored as a series of points, and stroke properties are derived from proximity to the original path. Perhaps there is an option to output more explicit information so that anything building on top of powerstroke can use it? If there is no possibility of outputing a kind of cache of powerstroke info, are there easy to use functions in the actual code to get this kind of information? I have been working on a mesh along path interface (not quite directly in inkscape yet), which could be adapted to apply gradients perpendicular to paths, make paths change color in the path direction, or perhaps be a base for inserting series of etching lines that conforms to a base path. Having access to powerstroke width profiles would be a great asset for these kinds of extensions. 2. Does the powerstroke computer apply the width always centered on the path? If the top and bottom were allowed to operate independently, it would be a single interface for both line offsetting (with only one powerstroke point) and for powerstroking itself. Thinking ahead to animation, tweaks like this could be useful there. -Tom ------ tomlechner.com

2 1

Re: [Inkscape-devel] lib2geom development, make test fail?
by Andreas Lobinger 17 Dec '13

17 Dec '13

Hello colleagues, 1) it's correct, the wiki points to a subversion repository https://lib2geom.svn.sourceforge.net/svnroot/lib2geom/lib2geom/trunk which i checked out as version r2059, the svn log | head tells me: lobi1@...3065...:~/lib2geom/trunk$ svn log | head ------------------------------------------------------------------------ r2059 | tweenk | 2010-07-21 22:18:35 +0200 (Mi, 21 Jul 2010) | 2 lines (and last check-in more than 3 years ago doesn't look like recent development...). This version runs cmake with everything found except: -- blas Includes, Compile and Link Flags: NOT FOUND -- pycairo Includes, Compile and Link Flags: NOT FOUND generates a makefile, make breaks with: lobi1@...3065...:~/lib2geom/trunk$ make [ 1%] Building CXX object src/2geom/CMakeFiles/2geom.dir/affine.cpp.o In file included from /home/lobi1/lib2geom/trunk/src/2geom/affine.cpp:15:0: /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: error: ‘size_t’ was not declared in this scope /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: note: suggested alternatives: /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note: ‘std::size_t’ /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note: ‘std::size_t’ /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template argument 1 is invalid /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template argument 2 is invalid /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:53: error: ‘size_t’ has not been declared make[2]: *** [src/2geom/CMakeFiles/2geom.dir/affine.cpp.o] Error 1 make[1]: *** [src/2geom/CMakeFiles/2geom.dir/all] Error 2 make: *** [all] Error 2 which looks strangely as C++ header trouble. 2) I followed the link in http://inkscape.org/en/develop/getting-started/#bazaar and in section Inkscape development tells me:The geometry library lib2geom, written in C++, is intended to eventually become a separate project. You can get the latest version of lib2geom from its Launchpad repository<https://launchpad.net/lib2geom> . So i bzr from the launchpad repository, bzr log | head tells me: lobi1@...3065...:~/lib2geom/lib2geom$ bzr log | head ------------------------------------------------------------ revno: 2161 committer: Johan B. C. Engelen <j.b.c.engelen@...3066...> branch nick: lib2geom timestamp: Mon 2013-12-09 22:00:17 +0100 message: use proper std:: namespace for std::size_t, because of cstddef include. fixes build for some ppl ------------------------------------------------------------ which i considered a lot more recent. The cmake claims the same missing as above, make however runs through and produces both the library and the toy programs. make test fails as: ... 60% tests passed, 6 tests failed out of 15 Total Test time (real) = 1.00 sec The following tests FAILED: 2 - bezier-test (Failed) 3 - chain-test (Failed) 4 - path-test (Failed) 6 - sbasis-test (Failed) 8 - convex-test (Failed) 11 - cg-test (Failed) Errors while running CTest make: *** [test] Error 8 3) My system is a std 12.04 Ubuntu on lobi1@...3065...:~/lib2geom/lib2geom$ uname -a Linux mark 3.2.0-56-generic-pae #86-Ubuntu SMP Wed Oct 23 17:51:27 UTC 2013 i686 i686 i386 GNU/Linux ? Wishing a happy day, Andreas

3 2

Fwd: possible bug?
by TimeWaster 17 Dec '13

17 Dec '13

*push* if noone answers till tomorrow i will open a bug report for it. regards, TimeWaster -------- Original Message -------- Subject: [Inkscape-devel] possible bug? Date: 15.12.2013 16:15 From: TimeWaster <sebi@...2963...> To: Inkscape Devel Mailingliste <inkscape-devel(a)lists.sourceforge.net> Reply-To: i have the attached document: <svg [...] width="602.36218" height="336.04724" [...] viewBox="0 0 170 94.840002"> <sodipodi:namedview [...] inkscape:document-units="mm" [...] > in inkscape "custom size" is set to px, "default units" is set to mm. width and heigth are the size of the document in pixel, all other numbers are in mm. (they all have no unit specified, but i know it because of the dimensions of the drawing) shouldn't the width and height parameter be width="602.36218px" instead of width="602.36218" since the document wide unit is mm (even the viewBox is in mm)? i am using r12832 right now. i think this is related to https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed there, which i cannot confirm. and even if you say that width should always be in px, having no explicit unit given makes it harder (more obfuscated) for people to understand and parse the documents. regards, TimeWaster ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

lib2geom development, make test fail?
by Andreas Lobinger 17 Dec '13

17 Dec '13

Hello, i wanted to use lib2geom in an own project and have difficulties to compile and run correctly; so my co from bzr_lp can cmake, make, but make test fails (for 6 tests, starting with bezier). This is also visible in the toys. Can someone point me please, how to connect to the development and how and where to ask questions. It also would be nice, to clarify the dependencies (BLAS is not found, but it's not clear, what this means). Wishing a happy day, Andreas

2 1

Fwd: Re: [scribus-dev] C++11
by Johan Engelen 16 Dec '13

16 Dec '13

Hi all, I asked the Scribus guys what their plans are regarding C++11. They had not thought about it much, but I got a very interesting reply, that is relevant for us too. Please read below. regards, Johan -------- Original Message -------- From: - Thu Nov 07 23:35:19 2013 Date: Thu, 07 Nov 2013 02:21:04 +0100 From: Jean Ghali <jghali@...373...> To: Scribus Development Mailing List <scribus-dev@...3050...>, jbc.engelen@...2592... Subject: Re: [scribus-dev] C++11 Hi, For making the switch to C++11, all C++ dependencies have to be compiled using C++11 too. It is indeed dangerous to link C++11 objects and C++ objects compiled according to previous standards: - http://gcc.gnu.org/wiki/Cxx11AbiCompatibility - http://stackoverflow.com/questions/9408656/do-we-need-to-recompile-librarie… - http://stackoverflow.com/questions/10065055/why-is-stdlist-bigger-on-c11 So basically the main requirements for us to switch to C++11 would be that qt binaries provided by distros are compiled according to C++11. I don't known if this is the case currently but i doubt it. Cheers, Jean Ghali Le 06/11/2013 20:05, Johan Engelen a écrit : > Hi all, > I'm rooting for requiring C++11 for lib2geom ASAP. How badly would this hurt Scribus > development? ;) > Are there any plans about when to make the switch to C++11 for Scribus? > > (I'm not subscribed to the list, so please also send replies directly to my address) > > Cheers, > Johan > (Inkscape and 2geom developer)

2 3

Recognizing a circle from a 1 + 3N Bezier description?
by mathog 16 Dec '13

16 Dec '13

SVG has a radial gradient type but neither EMF nor EMF+ do. Instead EMF+ has a gradient type that can be generalized to a radial: set color1 at an interior point and color2 on a closed path around it, and the intermediate points' colors are determined by the position along the ray from the center to the bounding curve. When PowerPoint saves a radial gradient via "save picture as" to an EMF file it also creates an EMF+ description. In the cases tested those paths looks like this: 1213769.875000,856342.937500 < 1213769.875000,1358353.125000 806810.187500,1765312.875000 304800.000000,1765312.875000 < -197210.218750,1765312.875000 -604169.937500,1358353.125000 -604169.937500,856342.937500 < -604169.937500,354332.718750 -197210.218750,-52627.000000 304800.000000,-52627.000000 < 806810.187500,-52627.000000 1213769.875000,354332.718750 1213769.875000,856342.937500 < The first point has type "start" and all the others have type "Bezier. The "<" indicates the points that are actually on the circle, and the points are grouped to emphasize how they work. These correspond to this drawing, with the point at 9:00 repeated once: http://www.mathworks.com/matlabcentral/fx_files/6844/2/CircleApproxbyCubicB… If the goal is to import this gradient from the EMF+ this bezier must be recognized as a circle. That might also be worthwhile for other circles encoded as a similar path. Now if the circles were only ever encoded with 13 points in this manner it would be pretty easy to spot one and convert it to a circle. But there might be 25 points in another circle representation, or something else. Does anyone know of a relatively straightforward test to apply to a curve like this (1 + 3N Bezier points) to see if it is a circle (within an error limit)? For the gradients we also have the location of the center point, but that won't be true for general curves. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 4

better targets for task/note-annotations on website
by Jared Meidal 16 Dec '13

16 Dec '13

I really like how the new website is functioning and it seems a slick way to bring in users and developers both into engaging with Inkscape! I've seen a number of text notes appearing on page content which seem to be reminders for tasks or content-to-come. I'm really glad for the diversity of contributors on the site, but as notes/tasks/needs are published on the site (rather than actual useful content itself) I'd like to see an alternative destination established before these notes sit out there too long on our live site. For example, http://inkscape.org/en/download/windows/ contains the line at the top "[[website TODO : pretty buttons showing main download link, + maybe screenshots of the installer.]]" This is a useful reminder to the website author-community, but not text that should reside on the live site. Would a better action be to move these annotations into the launchpad templates/bugs area, or can the web CMS handle notes in the backend for the developers only? Thanks, --Jared

3 2

Dealing with OS reported bugs
by Kris De Gussem 16 Dec '13

16 Dec '13

Hi all I was wondering how to deal with bug reports automatically submitted by the operating system. It is often hard to verify for these bugs how exactly one could to provoke the issue but on the other hand it may be clear from the backtrace that some null pointer check (or related thing) is missing). See for example https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1172484 for which I added a patch. See for example https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1219264 which might be solved by trunk revision 12851 (or maybe revision 12838). Do we mark these reports as fix committed (although we do not know how to provoke the issue)? Do we add a patch and wait for a specific amount of time for reactions? Any experiences on how is it dealt with for Ubuntu? Kind regards K

2 1

Tutorials Gallery
by Martin Owens 11 Dec '13

11 Dec '13

I've added a simple rss feed to the tutorials page: http://inkscape.org/en/learn/tutorials/ It's pulling in items from my inkscape tutorials favorites folder on deviantArt and I think it looks rather nice. Thoughts? Martin,

4 5