November 2005 - Inkscape Devel

i18n-able docs
by Alexandre Prokoudine 17 Nov '05

17 Nov '05

Hi, Is there any reason to keep i18n-able files keys.xml, keys.fr.xml etc. in 'docs ' directory of HEAD branch instead of doc-docbook branch? Alexandre

1 0

Retention of modified rotation centres
by John Cliff 17 Nov '05

17 Nov '05

Hi all, I've just commited some code that makes inkscape retain the centre of rotations location after you move it so that next time you come back to it the centre is where you put it. Allows you to do things like this: http://rapidshare.de/files/7501289/JCB_demo_XVID.avi I'm looking at adding a way to make it return to being centred, Scislac suggested ctrl+click, which unless anyone has any other suggestions is the way I'm gonna go. cheers Sim __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

5 4

white border around images
by John Taber 16 Nov '05

16 Nov '05

I've noticed I get a white border around png images that are opened and then copy and pasted into an inkscape drawing (I don't think the images themselves have the border - I've trimmed them in Gimp) - not sure what is causing this - any ideas how to fix ?

2 3

Inkscape-0.42+0.43pre3-1.dmg fails on OSX 10.3.9/X11
by Rasca 15 Nov '05

15 Nov '05

Hi, I tried the package Inkscape-0.42+0.43pre3-1.dmg on a MacOSX machine with OSX 10.3.9 and X11 installed from the OSX Cdrom. Sad, but it doesn't launch. When I try to use the command line, then I see that the binary is missing a dynamic library (libXinerama.1.dyn) which seems not to be included in the apple X11 distribution. Any ideas? If you have the solution please add also a README to the *.dmg to point to this. I'm sure I'm not the only one.. thx + cu rasca PS: same for the previous version Inkscape-0.42+0.43pre2-1.dmg

3 7

Win32 Text
by Joshua A. Andler 15 Nov '05

15 Nov '05

Since Richard's recent changes with the text stuff on win32, the text rendering is horribly broken for some reason (text is basically microscopic). I didn't want to throw this in the tracker yet, because we'll be hit pretty hard once .43 releases (but will do so if I don't see a response within a few days). I did have Aaron confirm it as well, so I know it's not just my box. Richard, I know you said it doesn't affect you, but if it's affecting the two of us, something is definitely not right. Do you have something different lib-wise by chance? -Josh

3 2

WEBFORM How to draw or insert a 9X9 grid Sudoku table
by Henry Kwok 14 Nov '05

14 Nov '05

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Henry Kwok email: hklksk@...1078... submitted the following: Enter your message or news here. Dear Sir I could not find any instruction from \"Help\" or your website about how to use Inkscape to draw or insert a 9x9 grid Sudoku table with number text written on the lines between each cell. Can you please advise me on this. Thanks With regards Henry Kwok

2 1

canvas: backing store, etc
by unknown＠example.com 14 Nov '05

14 Nov '05

bulia's work with canvas has inspired me to take a look at canvas code myself, and I've noticed one area where we could probably do better is to start using a persistent backing store for the canvas widget. Of course, X is supposed to provide that (although in XFree86 the backing store facility has been broken for years). So, I don't know -- is this something we should bother with ourselves, or rely on X to fix it eventually? It looks like we don't get a backing store on Windows either, though. Also, I think I've found another reason (besides cache effects) why increasing the tile size beyond 1M decreases painting performance: there is an optimization in the tile code such that if the entire tile is empty, it gets drawn with a rectangular fill instead of a blit. The larger the tile size, the less likely the optimization is to be employed. Probably also one of the other reasons why Lauris went with the small tile size (though as bulia has demonstrated, it was TOO small). I wonder if there's a way to take advantage of this optimization without having to re-tesselate for every single tile? Nathan suggested keeping a BSP once, which would be one option, but I'm not sure how to (efficiently) get there from livarot. Ideally, we should be able to tesellate once for the entire viewport, and then selectively blit/fill regions of that. -mental

1 0

svn's branch-merge to mitigate deps; cairo, gtkmm 'trainwreck'
by Jeff Kowalczyk 13 Nov '05

13 Nov '05

First, my sincere thanks to the Inkscape developers. You've developed a remarkable program in a very short time. The future ubiquity of SVG on several platforms owes a huge debt of gratitude to Inkscape and the people behind it. I noted the recent concern about which versions of various libraries (gtkmm, etc.) Inkscape should target for maximum benefit. See "newest gtkmm needed to compile HEAD" and "train wreck...") As a Gentoo user (i.e. self-imposer of trainwrecks), I periodically compile Inkscape-cvs against very recent gtk gtkmm, cairo etc. Anything older than the latest Ubuntu seems positively fossilized to my biased point of view. When I see mention of various cool features that developers have running in a private sandbox, I think it speaks to Inkscape's extreme need for a source repository that provides better support for branching and merging. I think Inkscape needs to migrate its source to subversion, and let the various devs maintain according to their interest: short-lived feature branches, long-lived maintenance branches, and convenient build bundles (svn:externals), to push the bleeding edge and still satisfy the slower pace of disto compatibility. Inkscape has a primary role to play in the SVG revolution on the GNOME and KDE linux desktops; it can't afford to lag behind the recent graphics libraries on which Cairo is being developed. At the same time, Inkscape needs to build packages for distros (and platforms) in various degrees of stability and vintage. Subversion could facilitate things the Inkscape developers are already trying to do. Using svn:externals, bundles could be maintained that would provide every conceivable combination of dependency, and a high probability of build success. A simple 'svn switch' would allow one to try out that latest cool feature mentioned one the mailing list, and come back to a safer branch without hassle if the feature isn't fully cooked. Just my $0.02, Inkscape is an amazing program with equally admirable community effort behind it. Keep up the good work.

6 7

NEW: speedups, Outline mode
by bulia byak 13 Nov '05

13 Nov '05

(This and the following messages describe new stuff in CVS and thus in 0.44, not 0.43) Recently I committed a few rendering speedup patches that I've been testing for a few weeks. It's still far from Xara speed, but the difference is noticeable. 1. As you probably noticed, screen redraw is done in chunks (typically horizontal strips). The maximum size of the chunk was 64K, which is pretty small. (Lauris had a strange idea that Sodipodi must run fine on a system with 32Mb RAM.) On the other hand, rendering each chunk causes a complete stroking and uncrossing of the paths touched by the chunk, which is especially expensive for paths with strokes, and even more so for dash patterns. This means the monstrous livarot functions were called a lot more often than necessary. I increased the chunk size to 256K, and that helped a lot. In some critical situations (complex stroked/dashed paths at high zooms) it's now up to 3 times faster; typically at least 10% faster. Node editing is also noticeably snappier because it involves a lot of path rendering. I then tried 1M chunks, but even though this made stroke/path rendering still faster, for some reason it slowed down rendering of files with lots of semitransparent gradients. So in the end, I settled on 256K. The gradient slowness with large chunks needs further investigation. 2. When rendering transparent overlays, Inkscape spends a lot of time calculating NR_PREMUL(c,a) defined as (((c) * (a) + 127)/255). I changed the division to FAST_DIVIDE_BY_255(v) ((((v)<< 8) + (v) + 257) >> 16) borrowed from Mozilla and got about 10% speedup on complex documents with transparency. 3. An error in sp-canvas.cpp caused a complete extra screen redraw after each zoom operation. That is, after you press "+" in a complex drawing, Inkscape redraws, but for some time after that it remains still unresponsive because it does that second redraw (invisibly for you, i.e. nothing changes on the screen). I fixed that, and now zooming is much more pleasant in complex docs. 4. It turned out pretty easy to code an Outline ("wireframe") display mode. In it: - all paths and shapes are shown as inverse (black on light background and vice versa) outlines of constant width (i.e. 1 screen pixel regardless of zoom), without fill; - text is painted by inverse fill color without stroke; - bitmaps are shown as is; - any opacity and gradients are ignored. Since Inkscape's display of path strokes is the slowest part of its renderer, the outline mode is usually not drastically faster than regular mode (usually 10% to 50% faster), and in some cases it may even be slower. However, the value of the outline mode is not only in its speed; it is a good way to get an idea of the structure and objects of your document, and it is convenient for precision node editing and for finding "stray objects". The switch from normal to outline view and back (View > Display mode) works on the fly. (As for a non-AA mode, I have no idea how to do it, and anyway I doubt that it will give a noticeable speedup at all.) I'm also really looking forward to Xara opening its code. I do plan to attempt to borrow their renderer, or parts thereof, into Inkscape, now that I know that ins and outs (but not the guts) of our own renderer fairly well, but I cannot promise anything - this may turn out prohibitively difficult. We'll see. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

7 11

New warnings (was Re: inkscape build report)
by Bryce Harrington 13 Nov '05

13 Nov '05

Three new warnings popped up in the build today... Bryce ----- Forwarded message from root <root@...1070...> ----- Date: Sat, 12 Nov 2005 17:21:02 -0800 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Sat Nov 12 15:54:54 2005 (Run 747) Snapshot: inkscape-20051112-1440.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 7 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == seltrans.cpp:651: warning: `void sp_sel_trans_handle_click(SPKnot*, unsigned int, void*)' defined but not used sp-item.cpp:151: warning: converting to non-pointer type `double' from NULL sp-item.cpp:152: warning: converting to non-pointer type `double' from NULL display/canvas-arena.cpp:87: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:87: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:133: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:133: warning: (perhaps the `offsetof' macro was used incorrectly) == Environment Summary == ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0