May 2008 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] [Lib2geom-devel] GSL dependency
by Marco 07 May '08

07 May '08

On Tue, 06 May 2008 23:00:47 +0200, <J.B.C.Engelen@...1578...> wrote: > Windows! :-) > > More important, if GSL becomes hard dependency, it becomes a hard > dependency for Inkscape as well. > > Cheers, > Johan > >> -----Original Message----- >> From: lib2geom-devel-bounces(a)lists.sourceforge.net >> [mailto:lib2geom-devel-bounces@lists.sourceforge.net] On Behalf Of njh >> Sent: dinsdag 6 mei 2008 22:35 >> To: Engelen, J.B.C. (Johan) >> Cc: lib2geom-devel(a)lists.sourceforge.net >> Subject: Re: [Lib2geom-devel] GSL dependency >> >> It should be part of your distribution. It is in ubuntu, for example. >> >> njh >> >> On Tue, 6 May 2008 J.B.C.Engelen@...1578... wrote: >> >> > Hi all, >> > >> > Recent commits made GSL a hard dependency, is that desired? >> > >> > And more important: where do i get it? >> > inkscape.modevia.com has an old gsl package, is that good enough? >> > >> > Regards, >> > Johan >> > >> > I used GSL for finding the roots of a 4th degree polinomial in the nearest point routine for elliptical arc and I'll need of the GSL library again to solve a 5x5 linear system for the elliptical arc fitting problem. So I'd like that GSL becames a hard dependency, but obviously I'm open to alternative solutions. Implementing these tools by myself could be a solution but it wouldn't be a little effort. So if there are real points against making GSL a hard dependency I'd whish to know them as soon as possible. You can download Windows binaries and developer files from here: http://gnuwin32.sourceforge.net/packages/gsl.htm and this is the gnu home page: http://www.gnu.org/software/gsl/ Cheers, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4 5

Re: [Inkscape-devel] [Lib2geom-devel] GSL dependency
by Marco 07 May '08

07 May '08

On Wed, 07 May 2008 02:01:21 +0200, njh <njh@...1927...> wrote: > On Wed, 7 May 2008, Bill Baxter wrote: > >> I said "seems" :-) >> >> But I was referring more to this list of things it does, of which only >> two are apparently needed: > > I agree, although we will probably use least squares in the near future. > Copying the appropriate files across is certainly a reasonable solution, > and the one I would advocate at the moment. > > (although solving linear systems I would class as something you _don't_ > want to be doing yourself, and my past experience timing things showed > that it was darned hard to beat the performance of GSL for root finding > and linear systems (well that's blas really)) > > Anyway, I propose we copy the files from gsl exactly as they are, and > default to using GSL is available on the grounds that it has code to use > SSE/MMX/Transputer when available. > > njh Copying across the needed files could be a sensible solution, even if this means we need finding out all the various inner GSL file dependencies. GSL is a well established numerical library with really good performance and it supports a lot of platforms. We can't hope to find one library that perfectly fits our needs, and I suppose that we all agree that is not useful to reinvent the wheel. There are problems that own both a geometric and a numerical aspect, and 2geom should offer a specific implementation for these problems, but not for basic numerical algorithms. So, how much should we exploit GSL ? As little as possible but not less. Moreover, I like the idea to make up some wrapper for the needed functionalities, so weakening the source code tie with the library. Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

1 0

Animation (was: Re: Inkscape / GSoC '08 proposal)
by Christophe Dehais 07 May '08

07 May '08

Hi Martin and everyone! On Tue, Feb 26, 2008 at 9:56 AM, Martin Owens <doctormo@...400...> wrote: > > If anyone is looking for a small simple project that would make great > impact they should think about working with me on the simple animation > plan; although I've not had a lot of time to work on it other than > reading inkscape codebase, I do believe the plan to be a solid > starting point. > I might actually be interested in this. I don't know what you have in mind precisely about "the simple animation plan", but here are the main possible goals I see: * implement the svg animation elements : animate, set, animate{Motion|Color|Transform} * figure out a decent UI for editing animations: - a time-based (SMIL oriented) timeline editor to represent / move around keytimes (=keyframes except it's not frame-based but time-based) - an interpolation curves editor * design some animation-related on-canvas items, like: - trajectories (motion-paths) - temporarily overlayed (t-epsilon) / (t+epsilon) state of an object (to mimic onion skinning) Is that close to what you thought about ? There are a lot of open questions, like: - should there be an "animation mode" where the animated attributes values are edited, as opposed to a "normal mode" where it's the object attributes that are modified ? - SMIL semantic is quite rich: at first some things might be discarded like repetition or the possibility to define the start of an animation based of some events (e.g. user click or the end of another animation). Those things don't map well in a timeline UI which I guess is the way animators are used to think. - will the canvas scale well to preview large animations sufficiently smoothly ? Comments welcomed ! regards, Christophe

11 17

Re: [Inkscape-devel] [Lib2geom-devel] GSL dependency
by Bill Baxter 06 May '08

06 May '08

I said "seems" :-) But I was referring more to this list of things it does, of which only two are apparently needed: """ The complete range of subject areas covered by the library includes, Complex Numbers Roots of Polynomials Special Functions Vectors and Matrices Permutations Sorting BLAS Support Linear Algebra Eigensystems Fast Fourier Transforms Quadrature Random Numbers Quasi-Random Sequences Random Distributions Statistics Histograms N-Tuples Monte Carlo Integration Simulated Annealing Differential Equations Interpolation Numerical Differentiation Chebyshev Approximation Series Acceleration Discrete Hankel Transforms Root-Finding Minimization Least-Squares Fitting Physical Constants IEEE Floating-Point Discrete Wavelet Transforms Basis splines """ --bb On Wed, May 7, 2008 at 8:49 AM, njh <njh@...1927...> wrote: > On Wed, 7 May 2008, Bill Baxter wrote: > > > > GSL seems like a huge dependency to pull in just for some root finding > > and solving of small linear systems. > > I'd either rip the needed code out of GSL and put it into lib2geom > > directly, or just find some implementation of those two algorithms > > elsewhere. They're both standard fodder in numerical computing. Most > > any textbook on numerics covers those topics, for instance. > > > > By huge, you mean 27kB. (http://packages.ubuntu.com/hardy/gsl-bin) > > njh >

1 0

NEW: change in Transform dialog
by bulia byak 06 May '08

06 May '08

Previously, the Apply to each object separately checkbox had no effect for the Move tab. Now, if several objects are selected, this checkbox is on, and "Relative move" is on, each object is shifted relative to the closest selected object on the left (for X) or below (for Y). For example, if you have a horizontal row of objects and you move them relatively by X=5px with "Apply to each object separately" on, the leftmost object will shift by 5px, the next one to the right by 10px, and so on; the rightmost selected object is displaced by 5*n px where n is the number of selected objects. As a result, the distance in each pair of adjacent objects will increase by 5px and the whole row will be spaced out, much like a letterspacing adjustment spaces out a text string. Moving these objects by X=-5px will, conversely, squeeze them tighter together: the leftmost will move by -5px, the next one by -10px, and so on. For Y, the effect is the same except that the move starts from the object closest to the bottom (i.e. with smallest Y coordinate). When determining the order of shifting objects, for X, the left edges of their bounding boxes are sorted horizontally, and for Y, the bottoms of their bounding boxes are sorted vertically. Order of selecting the objects or z-order does not matter. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

LGM 2008
by Jon A. Cruz 06 May '08

06 May '08

So, Who all is going to make it to LGM for 2008? For those of us not able to make it there this year, knowing who could represent Inkscape and bring up issues, meet people, etc, would be very useful. Thanks.

3 2

Re: [Inkscape-devel] SimpleCrosser
by Diederik van Lierop 06 May '08

06 May '08

Op Di, 6 mei, 2008 09:53, schreef J.B.C.Engelen@...1578...: > Marco has the same problem in 2geom. I think it's a bug by design (the > closing segment does not belong to the domain of the path); we are > thinking about including it in the domain (while keeping the > representation the same as it is now). That's great, then all I have to do is just wait for the problem to be solved. I think I can do that ;-) Diederik

1 0

SimpleCrosser
by Diederik van Lierop 06 May '08

06 May '08

Hi, Maybe it's just me doing something wrong, but I cannot get an intersection with the _closing_ segment of a rectangle. The first three segments between the four points of the rectangle behave as expected and do intersect nicely, but it looks like the closing segments is discarded when using the SimpleCrosser(). Is this by design or a bug, or am I missing something? This behaviour introduces a bug in Inkscape's snapping mechanism. For a constrained snap, I need to find an intersection of a linesegment (in the direction of the constrained handle movement) with an arbitrary path, but this doesn't work for the closing segment. Regards, Diederik

2 1

Re: [Inkscape-devel] SimpleCrosser
by Diederik van Lierop 06 May '08

06 May '08

Sorry, I only intended to send a single copy of my mail to lib2geom-dev :-( Diederik Op Di, 6 mei, 2008 08:15, schreef Diederik van Lierop: > Hi, > > Maybe it's just me doing something wrong, but I cannot get an intersection > with the _closing_ segment of a rectangle. The first three segments > between the four points of the rectangle behave as expected and do > intersect nicely, but it looks like the closing segments is discarded when > using the SimpleCrosser(). > > Is this by design or a bug, or am I missing something? > > This behaviour introduces a bug in Inkscape's snapping mechanism. For a > constrained snap, I need to find an intersection of a linesegment (in the > direction of the constrained handle movement) with an arbitrary path, but > this doesn't work for the closing segment. > > Regards, > > Diederik > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java… > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Re: [Inkscape-devel] File import
by Bob Jamison 05 May '08

05 May '08

Or my favorite: http://wotsit.org >For unknown file extention names try: > >http://www.file-extensions.org/ >http://filext.com/ >

1 0