- Inkscape Devel - Inkscape Mailman

flowedText switch branch
by Martin Owens 28 Mar '14

28 Mar '14

Hi developers, I've been looking at merging the fix for bug lp:167335 in branch[1] The code looks reasonable, although light. I'm compiling the branch now although could find no mailing list discussion about it and the merge review thread is empty. Any issues with this code before I merge it in? Martin, [1] http://bazaar.launchpad.net/~novalis/inkscape/fix-167335

3 6

SpinachCon Results
by Martin Owens 27 Mar '14

27 Mar '14

Here are the results from the User UX testing yesterday. All testers/users were new to inkscape or had only used it briefly before. UX Problems Found: * 3 Users thought they could select a group by clicking on the whilespace between objects * View > Grid was found to be confusing, Perhaps change to "Show Grid" or "Grid Guides" or some such. * All users found Rows and Columns dialog hard or impossible to find. Once found, it was easy to use. All expected to find it under Align and Distribute dialog. * 1 user thought Export Bitmap would make a PDF and didn't expect PDF in "Save As" * 1 user had screen size issues where many elements were off the sides of the screen. * New users found it hard to locate rotate handles, slow clicking not expected. Some would use the transform dialog instead. * All users could not find document size settings. Expecting Edit > Crop to Selection or similar function. Bugs found: * 3D boxes don't align at all. Thanks to everyone who took part and helped test Inkscape. I think for v1.0 of inkscape we should focus on clearing up a lot of these user interface issues we have. More testing would be good too. Best Regards, Martin Owens

7 11

strange valgrind issues with style.cpp
by mathog 27 Mar '14

27 Mar '14

Markus Engel tells me that all of the clang compiler warnings are now gone. That is good news. There was one clang warning about style.cpp in the list, and I was hoping that the clang fix would resolve an annoying valgrind issue with that file. Sadly, retested with all of these new patches in place and it is still there. When this test is run: valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --track-origins=yes src/inkscape --file /tmp/small.emf >/tmp/vgJ.log 2>&1 (The input file doesn't matter, I just use that one because it has some text, in fact, if memory serves, the first such error appears even if no input file is used. Each test takes about 5 minutes to get to the point where the window can be closed.) there are problems like this (sorry about the wrap): ==14247== Conditional jump or move depends on uninitialised value(s) ==14247== at 0x836DFC3: Inkscape::Text::Layout::Calculator::_computeFontLineHeight(font_instance*, double, SPStyle const*, Inkscape::Text::Layout::LineHeight*, double*) (Layout-TNG-Compute.cpp:1054) ==14247== by 0x8370F36: Inkscape::Text::Layout::Calculator::_buildSpansForPara(Inkscape::Text::Layout::Calculator::ParagraphInfo*) const (Layout-TNG-Compute.cpp:1268) ==14247== by 0x837146A: Inkscape::Text::Layout::Calculator::calculate() (Layout-TNG-Compute.cpp:1584) ==14247== by 0xA24A387: ??? ==14247== Uninitialised value was created by a stack allocation ==14247== at 0x821BA60: sp_style_read_ilengthornormal(SPILengthOrNormal*, char const*) (style.cpp:3576) This is line 1054 in Layout-TNG-Compute.cpp switch (style->line_height.unit) { and for some reason valgrind thinks the ".unit" part is either itself uninitialized or the result of something else being uninitialized. Try to print that value immediately before that line and valgrind warns on the output statement. Now here is where it gets weird. sp_style_read_ilengthornormal() is not a complicated function, and when debug print statements are placed in it that print that value valgrind does not complain about accessing that memory location. If memset is used to clear every bit in "val" in that function at the top it does not fix the problem. Running Inkscape in gdb and catching the first place where it goes wrong (from the valgrind output and the print statements, used to show the function parameters and the memory locations) and then setting a watch on that memory location (unit is a bit range, so the whole byte must be watched) shows that _nothing_ touched it before it got to the place where valgrind shows an error. So in location A in the program memory location "M" is initialized, and some time later in location B in the program memory location "M" is no longer initialized as far as valgrind is concerned. (The values stored there are the same in both locations in the program.) For the piece de resistance, if there are a bunch of print statements in sp_style_read_ilengthornormal(), and this std::cout << "DEBUG ssri final unit " << val->unit << " val " << val << std::endl; is placed just above the closing bracket, and valgrind run again, the problem goes away. But that output line _alone_ is not sufficient to clear up the problem, there have to be a bunch of other output lines present. Even though valgrind warns the values all seem to be good. But valgrind is already packed to the gills with warnings and the last thing it needs is many more. I have seen issues like this before, although usually in C, and they usually turned out to be erroneous memory accesses that by chance landed on valid memory. Anyway, I'm glad the scanner is coming up clean, but there is still something wrong with style.cpp. Or at least valgrind thinks so. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Regression?
by Diederik van Lierop 26 Mar '14

26 Mar '14

Hi all, There's this annoying bug I've found in recent Inkscape builds, but I can't find any bug reports on it, so I figured I'd better ask here first: Every now and then I cannot select any object, except for text boxes. This happens only a few times per hour or so, and I cannot tell yet exactly how to reproduce it. Sometimes I can recover from this, but I cannot reproduce that either. Restarting Inkscape is one way to work around it. I think this only happens while translating or transforming objects. Is this just me, or has anyone else noticed this behavior too? If someone has any pointers as too what (recent) changes might have caused this, then I'll have a stab at fixing this. Thanks, Diederik PS: running a nightly PPA of Inkscape on Ubuntu 13.10

2 1

Fwd: Inkscape development
by Mohsena Akhtar 26 Mar '14

26 Mar '14

Dear concern(s), I am interested to work in inkscape development.I installed latest source code(0.48).But I can not run or compile the project of source code by terminal or editor .How can I do this?I am using ubuntu 12.04 and am trying with code blocks.But it shows error while running.Which will be the correct process?Please anybody help me.

2 1

Building with make
by Isobel Knowles 26 Mar '14

26 Mar '14

Dear Chaps, After much testing with different configurations on a couple of platforms, I think my Makefile is ready for you to try. As I said earlier, I have completely failed to get launchpad to work on my browser so I have worked on the only released version I could get my hands on - 0.48.4. Should you feel it is worthwhile continuing with this approach I am happy to port it to 0.48.5 and beyond. The purpose of my changes is to simplify the configuration and build process, to improve automation, and to do so in an easily-maintainable fashion. I recognise that the autotools and automake in particular, although superficially easy, perform a lot of heavy scripting to produce Makefiles which are far too complicated for most users to read. This in turn makes many developers wary of making anything but the simplest of changes. As a first step toward breaking down this barrier I have removed the need for automake and placed the make rules in plain sight. Although I am still using autoconf to configure the code, the configuration is now cleanly separated from the build itself, and is now simple enough that it can be done by hand without autoconf at all. The changes amount to this: - A bit of tweaking of the configure script to remove automake. - The removal of the myriad of automake files. - The creation of a Makefile which does pretty much everything automake did, but without the mystery. - Adding some convenient structures to aid debugging. - A small number of code fixes to deal with glaring bugs made evident by the above & to clean up the version number storage. (These have probably been fixed already.) I have tried to contain my changes to just autoconf/make-related matters so as to reduce the impact on those later versions of Inkscape which are currently unavailable to me. To keep my changes small I placed all the make stuff in one file. I appreciate this might rankle, but I felt it was best to concentrate on the overall problem for now and sort out the detail later. Please bear this in mind when you review the changes. I have tested the software on Linux with different libraries and compilers. One of the systems was a bang up-to-date Debian Wheezy. Therefore I suggest a developer with a Linux system be the first person to work with me. I have also tested (insofar as I can) a cross compilation with a Linux build machine. I feel confident this should work too, but there are bound to be a variety of problems which will come out of the woodwork. Builds on Windows/Mac should work, but are untested. In the process I couldn't help but notice the cxxtests directory appears to have bitrotted. Is this true of later versions? I have not addressed binary packaging yet because the documents I have seen seem inexplicably complex to me. If someone could tell me how it is actually done on the various platforms I can automate them as well. Source packaging is done. I have documented my changes to the build process in INSTALL and in the Makefile itself but am happy to improve them at your suggestion. This is a work-in-progress. Assuming broad agreement, I would like to: - port it to an up-to-date version, - iron-out the platform issues, - address packaging and distribution, - fix and automate testing, - address linking, libraries and source file grouping, and - attack the many compilation warnings. in the next few weeks. Without further ado, please find two attachments to this email. I have provided it this way to keep it small. You should: - Extract 0.48.4 into a directory and change into it. - Extract the two attachments to this email into that directory. - rm `cat delete-list` - patch -p1 -E -i diffs - rm delete-list diffs - Read INSTALL and the other files it points to. - autoconf configure.ac > configure - Configure, make, install and prepare tar files like so: sh ./configure make -j 6 make install DESTDIR=foo make dist adjusting to your taste. Also try sh ./configure --help to see the new options. Regards, Is.

4 7

Possible problem in Geom::Path
by Markus Engel 25 Mar '14

25 Mar '14

Hi, In 2geom/path.cpp, ll 338-340, the following can be found: // this approach depends on std::vector's behavior WRT iterator stability get_curves().erase(first_replaced, last_replaced); get_curves().insert(first_replaced, first, last); get_curves() returns a std::vector&, all parameters are iterators. Both the comment and a failed debug assertion (Expression: vector insert iterator outside range) made me look this case up and I'm quite sure that this is not allowed: std::vector::erase Iterator validity Iterators, pointers and references pointing to position (or first) and beyond are invalidated [.]. http://www.cplusplus.com/reference/vector/vector/erase/ So (at least) first_replaced is invalid in the second line. Can anyone confirm this? Is there an easy workaround? Regards, Markus

2 2

setAttribute std::string or Glib::ustring
by Johan Engelen 25 Mar '14

25 Mar '14

Hi all, To easier use repr->setAttribute, I want to add two extra (overloaded) functions virtual void setAttribute(gchar const *key, gchar const *value, bool is_interactive=false)=0; virtual void setAttribute(gchar const *key, Glib::ustring const &value, bool is_interactive=false)=0; virtual void setAttribute(Glib::ustring const &key, Glib::ustring const &value, bool is_interactive=false)=0; Should I use std::string or Glib::ustring for this? Thanks, Johan

3 7

clang static analysis report
by Markus Engel 25 Mar '14

25 Mar '14

Hi, here's the results of running scan-build on a part of the sources. I interrupted it, this takes quite a while. Anyway, you've got 263 possible bugs to check. Either there are many false positives or. inkscape shouldn't even start :) . Open index.html: https://db.tt/3Nj4vpmG Regards, Markus

2 3

Re: [Inkscape-devel] clang static analysis report
by Johan Engelen 24 Mar '14

24 Mar '14

(back to list) On 24-3-2014 23:58, mathog wrote: > 4. I don't understand what it is warning about at line 706 in > upmf.c. It doesn't like this: > > int U_DPO_free(U_DPSEUDO_OBJ **dpo){ > if(!dpo){ return(0); } > if(!*dpo){ return(1); } > U_DPSEUDO_OBJ *kpo = *dpo; > if(kpo->poPoints){ U_PO_free(&kpo->poPoints); } > if(kpo->poTypes){ U_PO_free(&kpo->poTypes); } // <------ > free(*dpo); > *dpo=NULL; > return(1); > } > > At the arrow it gives the warning: "Branch condition evaluates to a > garbage value" > > The U_DPSEUDO_OBJ struct looks like this > > typedef struct { > uint32_t Elements; /**< Element count, applies to both > PseudoObjects */ > U_PSEUDO_OBJ *poPoints; /**< Points in path */ > U_PSEUDO_OBJ *poTypes; /**< Types of points in path */ > } U_DPSEUDO_OBJ; > > and this is U_PO_free() > > int U_PO_free(U_PSEUDO_OBJ **po){ > if(!po)return(0); > if(!*po)return(1); > if((*po)->Data)free((*po)->Data); > free(*po); > *po=NULL; > return(1); > } As you can read on the webpage that scan-build generates, there are 18 steps involved. The reason that line 706 is bugged is because for some control flow "kpo->poTypes" has a garbage value. The cause is that for the control flow indicated, the U_DPSEUDO_OBJ *Path is never fully properly initialized, in particular kpo->poTypes isn't. -Johan

1 0