- Inkscape Devel - Inkscape Mailman

0.42: Call for screenshots!
by bulia byak 06 Jul '05

06 Jul '05

We need more screenshots for 0.42. I recently added one screenshot for the new Align options: http://inkscape.org/screenshots/index.php and we have enough screens for clone tiler and i18n, but for the rest of the features, submissions are solicited. We would appreciate both "demo" (focusing on features) and "work" (showing real work projects) screenshots. Here are some requirements: - 1280x1024 PNG - Visually interesting. It's not to be a design masterpiece but it must not be too ugly, too unbalanced, etc. - Sufficiently informative. We can't have too many screenshots on that page, so we must try to cram as much stuff as possible into each screenshot. Don't waste space. Add objects, captions, explanations. Open dialogs, switch tools, make tooltips appear before shooting. Use objects both large (visible on the thumbnail) and small (visible in full image only). Make each screenshot a story that invites close examination, thinking, and experimentation. The screenshots page is usually the first one that new users go to, so let's work on a 0.42 screenshots collection that makes justice to this great release. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Inkscape in gentoo
by Bryce Harrington 06 Jul '05

06 Jul '05

Good news: Gentoo has just upgraded to Inkscape 0.41 as stable on x86 and four other platforms: http://packages.gentoo.org/search/?sstring=inkscape :-) Bryce ----- Forwarded message from bugzilla-daemon@...599... ----- Date: Tue, 05 Jul 2005 08:36:04 +0000 From: bugzilla-daemon@...599... To: bryce@...260... Subject: [Bug 92995] media-gfx/inkscape-0.41-r1 stable request Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=92995 Secure: https://bugs.gentoo.org/show_bug.cgi?id=92995 zypher@...599... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From zypher@...599... 2005-07-05 01:36 PDT ------- Version 0.41-r1 marked stable. Thanks for your patience, I'll try to keep up a bit better next time ;) Cheers, Marc. -- Configure bugmail: http://bugs.gentoo.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ----- End forwarded message -----

4 4

Inkscape 0.42pre0
by Ted Gould 05 Jul '05

05 Jul '05

Yeah! Yeah! Yeah! Finally got distcheck to pass! https://sourceforge.net/project/showfiles.php?group_id=93438&package_id=991… If the people who can build binary packages would, then we can send an e-mail to the user's list for wider distribution. Whew! Thought that would never get out! --Ted

5 5

RDF id= fix
by MenTaLguY 05 Jul '05

05 Jul '05

Just a quick note that I've just fixed bug 1184252, where we had been adding id= attributes to elements under rdf:RDF in violation of the RDF/XML specification. Now we only add id= attributes to elements in the SVG, Sodipodi, and Inkscape namespaces. Also, I've added code to strip existing id= attributes from under rdf:RDF -- I figure that much is safe to do because it's clearly wrong for them to be there. Even so, I think it would be a good idea if someone went through and resaved all our document templates so they don't include the bogus attributes in their metadata. Volunteers? -mental

3 2

Updated spanish po in the patch tracker
by Lucas Vieites 04 Jul '05

04 Jul '05

Hi, I updated the spanish po in the patch tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1232277&group_id=9… -- Lucas Vieites Fariña <lucas@...212...> Web: <http://www.asixinformatica.com/users/lucas/> Blog: <http://www.asixinformatica.com/blog/>

1 0

Race condition in sp_gradient_invalidate_vector()?
by Ralf Stephan 04 Jul '05

04 Jul '05

Hello, both bugs 1038594 and 1196143 appear to be 'fixed' by not g_free'ing gr->color. This is a text gradient buffer mangled in both bugs (in 1196143 you can see some destruction of the picture when repainting after dialog release). In 1038594, valgrind tells me about attempted reads from the same address which was freed before, and gtk likely reuses the memory, and this fast. This would mean that there is a copy of the color buf somewhere that is not updated but I still am not well into the code. I would propose memory handling of this buffer to be moved into GC, before the release, or using malloc/free if that works. https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1038594&group_… https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1196143&group_… Regards, ralf

5 7

Removing C-Style casts
by Ben Fowler 04 Jul '05

04 Jul '05

In the file libnr/nr-point.h, there are some C-Style casts in the code: /** \brief A function to lower the precision of the point \param places The number of decimal places that should be in the final number. This function accomplishes its goal by doing a 10^places and multipling the X and Y coordinates by that. It then casts that to an integer (to get rid of all decimal points) and then divides by 10^places back again. */ inline void round (int places = 0) { _pt[X] = (Coord)(Inkscape::round((double)_pt[X] * pow(10, places)) / pow(10, places)); _pt[Y] = (Coord)(Inkscape::round((double)_pt[Y] * pow(10, places)) / pow(10, places)); return; } Now casting _pt[] to a double is no-op, and possibly the (Coord) cast is also unnecessary, or could be converted to a function-style one: Coord( ... ) . My problem centres on ensuring that the code matches the comment, which refers to casting to an int. I am fairly sure that the Inkscape::round( ) function actually is a wrapper around std::floor( ) which does everything in IEEE double precision. IMHO, the Coord type should have a round( ) function, which I have had to provide under a different name: namespace NR { /** - * A "real" type with sufficient precision for coordinates. + * A floating point type with sufficient precision for coordinates. * * You may safely assume that double (or even float) provides enough precision for storing * on-canvas points, and hence that double provides enough precision for dot products of * differences of on-canvas points. */ -typedef double Coord; + typedef double Coord; + + /** + \brief A function to lower the precision of a co-ordinate + \param places The number of decimal places that should remain in + this co-ordinate. + + This function accomplishes its goal by multipling the co-ordinate by + (10^places). It then uses the Inkscape round( ) function (currently + implemented with std::floor( )) to remove the surplus precision and + then divides by (10^places) to scale back again. + */ + inline Coord set_precision (Coord c, int places = 0) { +// g_assert( places > 0 ); // Assert on do-nothing calls and negative number of decimal places + double factor = pow(10, places); + return Coord((Inkscape::round(c * factor) / factor));; + } } /* namespace NR */ and then I can re-do the function as: /** \brief A function to lower the precision of the point \param places The number of decimal places that should remain in the co-ordinates of the point. */ inline void round (int places = 0) { // g_assert( places > 0 ); // Assert on do-nothing calls and negative number of decimal places _pt[X] = NR::set_precision(_pt[X], places); _pt[Y] = NR::set_precision(_pt[Y], places); return; } Is this the way to go? Would these changes be acceptable in any way? Should Coord be a class rather than a typedef? Should the round( ) function(s) which are really floor( ) functions be renamed? Should the round functions(s) which are really set_precision( ) (if any) be renamed? Should any of these functions be templates e.g. (untested) template <class T> inline void round( int places=0 ) { // round co-ordinates to places decimal places } How are modifications to working code meant to be tested? I would be happy to submit patches for review, or pursue this in any other way: I am trying to see whether it is viable to remove C-Style casts as per http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeJanitors

1 3

Win32 testers needed!
by Bryce Harrington 03 Jul '05

03 Jul '05

Hi all, We are closing in on the 0.42 release, and getting the last few bugs fixed. There are a _number_ of bugs which appear to be Windows-only. Unfortunately, since the developers are linux-based, it's hard to determine how to fix them and to check that the fixes worked. Thus, if you are a Windows Inkscape user, we really need your help right now, in the run up to the release. Please review the Bug Tracker, and in particular look at the bugs that are ranked at '9'. Install both 0.41 and a version from CVS, and try to recreate each bug on each copy. Then add a comment to the bug report about whether you can or cannot replicate the error. Make sure you're logged into SourceForge, so the developers can contact you with more questions or to verify if a change fixed it. If you do not have a SourceForge account, please include your email address. If you want to help even more, it is extremely valuable to have backtraces. You can learn how to make backtraces on the Report A Bug page on the website. The more you can do to help narrow in on where the bug occurs, the more quickly it can be fixed. Please try to find a couple evenings over the next week to devote to doing some testing; even if you can only test a few bugs, you will help make Inkscape on Windows that much more robust. Thanks, Bryce

1 0

New gtk bundle
by Bob Jamison 03 Jul '05

03 Jul '05

Hi, all, I uploaded another copy of the Win32 libs for the build. This one has xmlparse.dll and libtiff3.dll added, and some unnecessary files removed. It is here: http://inkscape.org/win32/ It is 7-zipped to reduce the size. 24mb is much nicer than 52. I added some lines to the 'dist' target of Makefile.mingw to use these files. Bob

2 2

win32 crash on creating about memory dialog
by Adib Taraben 02 Jul '05

02 Jul '05

Hi, on win32 the current cvs crashes after pressing "about memory" function. I use the new gtk26 libs from Bob. I tried this on linux and there it is ok. I have no glue whats going on as I don't know gtk. I think that has to be resolved before release, thats why I post here. Attached there is the bt: HTH, Adib. --- gdb: kernel event for pid=3976 tid=2572 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x05013750 Program received signal SIGSEGV, Segmentation fault. 0x05013750 in Glib::Object::Object (this=0x8326d98, __vtt_parm=0x8e4830, construct_params=@0x22ec80) at object.cc:214 in object.cc (gdb) 214 object.cc: No such file or directory. bt #0 0x05013750 in Glib::Object::Object (this=0x8326d98, __vtt_parm=0x8e4830, construct_params=@0x22ec80) at object.cc:214 #1 0x05fb5557 in Gtk::Object::Object (this=0x8326d98, __vtt_parm=0x8e482c, construct_params=@0x22ec80) at object.cc:35 #2 0x0073d895 in _fu56___ZTTN3Gtk14TreeViewColumnE () at c:/gtk26/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:848 #3 0x0073df3c in Gtk::TreeView::append_column<Glib::ustring> (this=0x8348fc4, title=@0x22edb0, model_column=@0x8348fa0) at c:/gtk26/include/gtkmm-2.4/gtkmm/treeview.h:1365 #4 0x007730f3 in Inkscape::UI::Dialog::Memory::Private::Private ( this=0x8348f90) at ui/dialog/memory.cpp:93 #5 0x0066ce55 in Inkscape::UI::Dialog::Memory::Memory (this=0x8337b98) at ui/dialog/memory.cpp:206 #6 0x00772d16 in Inkscape::UI::Dialog::Memory::create () at ./ui/dialog/memory.h:23 #7 0x007727a3 in Inkscape::UI::Dialog::(anonymous namespace)::create<Inkscape::UI::Dialog::Memory> () at ui/dialog/dialog-manager.cpp:46 #8 0x00511f91 in Inkscape::UI::Dialog::DialogManager::getDialog ( this=0x72b9dd8, name=1162) at ui/dialog/dialog-manager.cpp:137 #9 0x00511ff0 in Inkscape::UI::Dialog::DialogManager::showDialog ( this=0x72b9dd8, name=1162) at ui/dialog/dialog-manager.cpp:156 #10 0x00511fd6 in Inkscape::UI::Dialog::DialogManager::showDialog ( this=0x72b9dd8, name=0x85a9d2 "Memory") at ui/dialog/dialog-manager.cpp:149 #11 0x004d4076 in Inkscape::HelpVerb::perform (action=0x74cf990, data=0x95, pdata=0x0) at verbs.cpp:1472 #12 0x004e062a in sp_action_perform (action=0x74cf990, data=0x0) at helper/action.cpp:135 #13 0x0043767f in sp_ui_menu_activate (object=0x7526b28, action=0x74cf990) at interface.cpp:284

2 1