You can subscribe to this list here.
2007 
_{Jan}
(2) 
_{Feb}
(3) 
_{Mar}
(4) 
_{Apr}
(27) 
_{May}
(5) 
_{Jun}

_{Jul}
(14) 
_{Aug}

_{Sep}
(1) 
_{Oct}
(4) 
_{Nov}
(19) 
_{Dec}


2008 
_{Jan}
(8) 
_{Feb}
(1) 
_{Mar}
(4) 
_{Apr}
(28) 
_{May}
(77) 
_{Jun}
(79) 
_{Jul}
(112) 
_{Aug}
(36) 
_{Sep}
(33) 
_{Oct}
(19) 
_{Nov}
(9) 
_{Dec}
(11) 
2009 
_{Jan}

_{Feb}

_{Mar}
(12) 
_{Apr}
(11) 
_{May}
(13) 
_{Jun}
(23) 
_{Jul}
(5) 
_{Aug}
(25) 
_{Sep}
(9) 
_{Oct}
(22) 
_{Nov}
(16) 
_{Dec}
(5) 
2010 
_{Jan}
(23) 
_{Feb}
(12) 
_{Mar}
(5) 
_{Apr}
(29) 
_{May}
(4) 
_{Jun}
(9) 
_{Jul}
(22) 
_{Aug}
(2) 
_{Sep}
(10) 
_{Oct}
(6) 
_{Nov}
(8) 
_{Dec}

2011 
_{Jan}
(2) 
_{Feb}
(44) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(9) 
_{Jul}
(5) 
_{Aug}
(4) 
_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2012 
_{Jan}
(16) 
_{Feb}
(8) 
_{Mar}
(9) 
_{Apr}
(5) 
_{May}
(3) 
_{Jun}
(3) 
_{Jul}
(6) 
_{Aug}
(10) 
_{Sep}
(48) 
_{Oct}
(6) 
_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(19) 
_{Sep}
(3) 
_{Oct}
(5) 
_{Nov}
(35) 
_{Dec}
(3) 
2014 
_{Jan}

_{Feb}
(3) 
_{Mar}
(4) 
_{Apr}
(12) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3
(6) 
4
(1) 
5

6

7
(3) 
8

9

10
(1) 
11
(3) 
12

13
(4) 
14
(1) 
15

16

17

18
(3) 
19

20

21

22

23

24

25

26

27

28

29

30

31

From: Krzysztof Kosiński <tweenk.pl@gm...>  20091018 21:02:10

W dniu 18 października 2009 22:20 użytkownik <J.B.C.Engelen@...> napisał: > Hi all, > > I think there is a bug in the exponentiation method for Transforms. > See transforms.h, lines 86103. > Line 100 does something with 'result' but 'result' is never used again and is not returned..... > Please have a look and test this method for several values of n. Ugh, it's an obvious brain fart. The last line was supposed to read "return result;" instead of "return x;". Fixed in r2028. Regards, Krzysztof 
From: J.B.C.E<ngelen@ew...>  20091018 20:23:42

Hi all, I think there is a bug in the exponentiation method for Transforms. See transforms.h, lines 86103. Line 100 does something with 'result' but 'result' is never used again and is not returned..... Please have a look and test this method for several values of n. Ciao, Johan 
From: J.B.C.E<ngelen@ew...>  20091018 20:23:39

Hi all, I've started making a toy framework specifically for LPE's. Have a look at the lpetest toy. Stuff to do, for which I invite you to help:  more complicated input path (right now it is jst one bezier segment)  add lpe parameters (point, path, scalar) Cheers, Johan 
From: J.B.C.E<ngelen@ew...>  20091014 12:37:29

> Original Message > From: njh [mailto:njh@...] > Sent: Tuesday, October 13, 2009 23:54 > > On Wed, 14 Oct 2009, jf barraud wrote: > > > Reading the code, I think the convention is to use the > segment on the > > right (i.e. return the limit of f(t) when t>t0 with t>t0 ) > [the code > > is not very explicit about this point by the way, so this should be > > checked and made explicit in a comment]. > > I think we should use a consistant convention for evaluating the > > function and the derivatives, so I suggest returning the > "rightderivatives". > > Yes, this was my intent, but documenting and checking for > consistency would be a good idea. It'd better be the intent! ;) Inkscape depends on it! Do you guys want to have some kind of digital gettogether to start documenting this kind of stuff more in 2geom? :) Cheers, Johan 
From: njh <njh@nj...>  20091013 22:54:12

On Wed, 14 Oct 2009, jf barraud wrote: > Reading the code, I think the convention is to use the segment on the right > (i.e. return the limit of f(t) when t>t0 with t>t0 ) [the code is not very > explicit about this point by the way, so this should be checked and made > explicit in a comment]. > I think we should use a consistant convention for evaluating the function > and the derivatives, so I suggest returning the "rightderivatives". Yes, this was my intent, but documenting and checking for consistency would be a good idea. > The only other type of functions that can have singularities are fractions > P(t)/Q(t). We already have ratquad, and might want to have more (for > handling infinite curvature for instance). But because P and Q are > polynomials, singularities already show up at evaluation time, so here again > derivatives should simply follow the same convention as evaluation... Well there are the roots(Q/P) which are +/ inf njh 
From: jf barraud <jf.barraud@gm...>  20091013 22:14:55

Hi all, Strictly speaking, cusps are not an issue because on a curve t > (x(t),y(t)), they are the points where both dx/dt and dy/dt vanish... so the derivative still exists ;) But I agree cuts in pwsb are an issue: they are non smooth points. Notice they can even be discontinuity points so the question already exists for the evaluation. Reading the code, I think the convention is to use the segment on the right (i.e. return the limit of f(t) when t>t0 with t>t0 ) [the code is not very explicit about this point by the way, so this should be checked and made explicit in a comment]. I think we should use a consistant convention for evaluating the function and the derivatives, so I suggest returning the "rightderivatives". The only other type of functions that can have singularities are fractions P(t)/Q(t). We already have ratquad, and might want to have more (for handling infinite curvature for instance). But because P and Q are polynomials, singularities already show up at evaluation time, so here again derivatives should simply follow the same convention as evaluation... Cheers, jfb. 
From: J.B.C.E<ngelen@ew...>  20091013 20:46:01

I think in that case, it should still return a vector with size n+1, but filled with INF values or smth. Ciao, Johan > Original Message > From: Krzysztof Kosiński [mailto:tweenk.pl@...] > Sent: dinsdag 13 oktober 2009 22:15 > To: Engelen, J.B.C. (Johan) > Subject: Re: [Lib2geomdevel] Crasher... > > 2009/10/13 <J.B.C.Engelen@...>: > > Hey, > > > > I just changed all the valueAndDeriv stuff to always return > a vector > > of size n+1. This fixes a big bug in d2.h code :) > > > > Cheers, > > Johan > > What is returned when the derivative doesn't exist (e.g. at a > cusp)? I don't know whether 2Geom has curve types that can > have cusps, but they are theoretically possible. > > Regards, Krzysztof > 
From: J.B.C.E<ngelen@ew...>  20091013 20:08:41

Hey, I just changed all the valueAndDeriv stuff to always return a vector of size n+1. This fixes a big bug in d2.h code :) Cheers, Johan > Original Message > From: njh [mailto:njh@...] > Sent: maandag 12 oktober 2009 0:45 > To: Engelen, J.B.C. (Johan) > Cc: mail@...; lib2geomdevel@... > Subject: Re: [Lib2geomdevel] Crasher... > > If you ask for 3 v&ds and get less, the remainder are 0. > Perhaps it would be a good idea to fill with 0.s (I'm > surprised it isn't true) > > njh > > On Sun, 11 Oct 2009 J.B.C.Engelen@... wrote: > > > Hi guys, > > > > Seems the bug was already fixed in 2geom. > > However, I have a question about the > Bezier::valueAndDerivatives(Coord > > t, unsigned n_derivs) method. > > Now, the size of the returned vector equals n_derivs+1 with > a maximum > > of order()+1. Aren't higher order derivatives just zero and > shouldn't > > we return those too if requested? > > It is very inconvenient if the size of the returned vector is > > determined by the particular bezier type. Because you usually don't > > want to know the type of the curve. > > E.g. > > Curve c = getcurve(); > > derivs = c.valueAndDerivatives(0, 3); > > > > Currently, one does not know the size of derivs. It is not > possible to > > simply do derivs[2] to get the 2nd derivative without > crashing in some > > cases..... very annoying! > > Shall we reprogram the method to always return a vector with size > > n_derivs+1? > > This is what D2:valueAndDerivatives expects!! (that's why 2geom > > sometimes crashes... see d2.h line 102) > > > > Ciao, > > Johan > > > > > > > >> Original Message > >> From: Diederik van Lierop [mailto:mail@...] > >> Sent: zaterdag 10 oktober 2009 23:52 > >> To: lib2geomdevel@... > >> Subject: [Lib2geomdevel] Crasher... > >> > >> Hi 2geom gurus, > >> > >> Looks like we have a crasher in Inkscape caused by 2geom, > but I got > >> stuck and need some help. I got quite far in tracing this, > so could > >> you please see if you can reproduce this XP only bug and > take it from > >> where I left it? > >> > >> See > >> > >> https://bugs.launchpad.net/inkscape/+bug/425557/comments/18 > >> > >> Many thanks, > >> > >> Diederik > >> > >>  > >>  > >> Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > >> is the only developer event you need to attend this year. > Jumpstart > >> your developing skills, take BlackBerry mobile > applications to market > >> and stay ahead of the curve. > >> Join us from November 9  12, 2009. Register now! > >> http://p.sf.net/sfu/devconference > >> _______________________________________________ > >> Lib2geomdevel mailing list > >> Lib2geomdevel@... > >> https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > >> > > > > >  > >  Come build with us! The BlackBerry(R) Developer > Conference in > > SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile > applications > > to market and stay ahead of the curve. Join us from > November 9  12, > > 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Lib2geomdevel mailing list > > Lib2geomdevel@... > > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > > > 
From: njh <njh@nj...>  20091011 23:45:19

If you ask for 3 v&ds and get less, the remainder are 0. Perhaps it would be a good idea to fill with 0.s (I'm surprised it isn't true) njh On Sun, 11 Oct 2009 J.B.C.Engelen@... wrote: > Hi guys, > > Seems the bug was already fixed in 2geom. > However, I have a question about the Bezier::valueAndDerivatives(Coord > t, unsigned n_derivs) method. > Now, the size of the returned vector equals n_derivs+1 with a maximum of > order()+1. Aren't higher order derivatives just zero and shouldn't we > return those too if requested? > It is very inconvenient if the size of the returned vector is determined > by the particular bezier type. Because you usually don't want to know > the type of the curve. > E.g. > Curve c = getcurve(); > derivs = c.valueAndDerivatives(0, 3); > > Currently, one does not know the size of derivs. It is not possible to > simply do derivs[2] to get the 2nd derivative without crashing in some > cases..... very annoying! > Shall we reprogram the method to always return a vector with size > n_derivs+1? > This is what D2:valueAndDerivatives expects!! (that's why 2geom > sometimes crashes... see d2.h line 102) > > Ciao, > Johan > > > >> Original Message >> From: Diederik van Lierop [mailto:mail@...] >> Sent: zaterdag 10 oktober 2009 23:52 >> To: lib2geomdevel@... >> Subject: [Lib2geomdevel] Crasher... >> >> Hi 2geom gurus, >> >> Looks like we have a crasher in Inkscape caused by 2geom, but >> I got stuck and need some help. I got quite far in tracing >> this, so could you please see if you can reproduce this XP >> only bug and take it from where I left it? >> >> See >> >> https://bugs.launchpad.net/inkscape/+bug/425557/comments/18 >> >> Many thanks, >> >> Diederik >> >>  >>  >> Come build with us! The BlackBerry(R) Developer Conference in >> SF, CA is the only developer event you need to attend this >> year. Jumpstart your developing skills, take BlackBerry >> mobile applications to market and stay ahead of the curve. >> Join us from November 9  12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Lib2geomdevel mailing list >> Lib2geomdevel@... >> https://lists.sourceforge.net/lists/listinfo/lib2geomdevel >> > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20091011 21:48:28

2009/10/11 <J.B.C.Engelen@...>: > Hi guys, > > Seems the bug was already fixed in 2geom. > However, I have a question about the Bezier::valueAndDerivatives(Coord > t, unsigned n_derivs) method. > Now, the size of the returned vector equals n_derivs+1 with a maximum of > order()+1. Aren't higher order derivatives just zero and shouldn't we > return those too if requested? The current behavior is counterintuitive for me too. I think the original reasoning was that it could return less than n_derivs+1 elements if some of the higher derivatives don't exist. But Bezier curves and polynomials in general have an infinite number of derivatives ("almost all" of them zero). Seems like somewhere along the way someone confused a zero derivative with no derivative. Regards, Krzysztof 
From: J.B.C.E<ngelen@ew...>  20091011 18:54:38

Hi guys, Seems the bug was already fixed in 2geom. However, I have a question about the Bezier::valueAndDerivatives(Coord t, unsigned n_derivs) method. Now, the size of the returned vector equals n_derivs+1 with a maximum of order()+1. Aren't higher order derivatives just zero and shouldn't we return those too if requested? It is very inconvenient if the size of the returned vector is determined by the particular bezier type. Because you usually don't want to know the type of the curve. E.g. Curve c = getcurve(); derivs = c.valueAndDerivatives(0, 3); Currently, one does not know the size of derivs. It is not possible to simply do derivs[2] to get the 2nd derivative without crashing in some cases..... very annoying! Shall we reprogram the method to always return a vector with size n_derivs+1? This is what D2:valueAndDerivatives expects!! (that's why 2geom sometimes crashes... see d2.h line 102) Ciao, Johan > Original Message > From: Diederik van Lierop [mailto:mail@...] > Sent: zaterdag 10 oktober 2009 23:52 > To: lib2geomdevel@... > Subject: [Lib2geomdevel] Crasher... > > Hi 2geom gurus, > > Looks like we have a crasher in Inkscape caused by 2geom, but > I got stuck and need some help. I got quite far in tracing > this, so could you please see if you can reproduce this XP > only bug and take it from where I left it? > > See > > https://bugs.launchpad.net/inkscape/+bug/425557/comments/18 > > Many thanks, > > Diederik > >  >  > Come build with us! The BlackBerry(R) Developer Conference in > SF, CA is the only developer event you need to attend this > year. Jumpstart your developing skills, take BlackBerry > mobile applications to market and stay ahead of the curve. > Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > 
From: Diederik van Lierop <mail@di...>  20091010 21:50:48

Hi 2geom gurus, Looks like we have a crasher in Inkscape caused by 2geom, but I got stuck and need some help. I got quite far in tracing this, so could you please see if you can reproduce this XP only bug and take it from where I left it? See https://bugs.launchpad.net/inkscape/+bug/425557/comments/18 Many thanks, Diederik 
From: J.B.C.E<ngelen@ew...>  20091007 21:51:10

> roots(dot(derivative(B), direction)) Wow, this is quite nice syntax! So I can dotproduct the derivative*function* with a direction? And then solve that for zeroes? niccccce > Original Message > From: njh [mailto:njh@...] > Sent: woensdag 7 oktober 2009 22:38 > To: Engelen, J.B.C. (Johan) > Cc: lib2geomdevel@... > Subject: Re: [Lib2geomdevel] searching for derivative on paths... > > roots(dot(derivative(B), direction)) > > (which is essentially the same as yours) > > On Wed, 7 Oct 2009 J.B.C.Engelen@... wrote: > > > Hi all, > > > > I'd like to find all locations on a path that have a > tangent equal to > > some vector A. > > Is there a method in 2geom that already does this? > > Otherwise, I figured I can code it myself. What I come up with now: > > 1. rotate path such that A is horizontal 2. for each segment of a > > path, find where yderivative equals zero > > > > Cheers, > > Johan > > > > >  > >  Come build with us! The BlackBerry(R) Developer > Conference in > > SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile > applications > > to market and stay ahead of the curve. Join us from > November 9  12, > > 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Lib2geomdevel mailing list > > Lib2geomdevel@... > > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > > > 
From: njh <njh@nj...>  20091007 21:39:03

roots(dot(derivative(B), direction)) (which is essentially the same as yours) On Wed, 7 Oct 2009 J.B.C.Engelen@... wrote: > Hi all, > > I'd like to find all locations on a path that have a tangent equal to > some vector A. > Is there a method in 2geom that already does this? > Otherwise, I figured I can code it myself. What I come up with now: > 1. rotate path such that A is horizontal > 2. for each segment of a path, find where yderivative equals zero > > Cheers, > Johan > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > 
From: J.B.C.E<ngelen@ew...>  20091007 20:59:27

Hi all, I'd like to find all locations on a path that have a tangent equal to some vector A. Is there a method in 2geom that already does this? Otherwise, I figured I can code it myself. What I come up with now: 1. rotate path such that A is horizontal 2. for each segment of a path, find where yderivative equals zero Cheers, Johan 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20091004 20:17:05

W dniu 4 października 2009 00:56 użytkownik njh <njh@...> napisał: > The problem is that the operator* was relying on the target being separate > memory. You changed it on the presumption that update in place would work, > which it doesn't (because matrix multiply permutes the elements). So does the problem manifest itself only when a = a * b? Or did I write an incorrect definition of operator*=? I don't know which line in the matrixinv.cpp test exhibits the problem. Was it already fixed by somebody else? I removed the operator helper for Matrix multiplication and redefined *= in terms of * as it should be more efficient, but my tree doesn't build at the moment, so I'm attaching it here instead. Regards, Krzysztof 
From: njh <njh@nj...>  20091003 23:56:47

On Sun, 4 Oct 2009, [UTF8] Krzysztof Kosi?ski wrote: > W dniu 4 paÿÿdziernika 2009 00:12 uÿÿytkownik njh <njh@...> napisaÿÿ: >> afaict, you changed the multiply from the c = a*b form to a *= b, which >> broken it. > > The helper is implemented as follows: > > Matrix operator*(Matrix const &a, Matrix const &b) { > Matrix temp(a); > temp *= b; > return b; > } > > The breakage is rather weird. operator* cannot overwrite anything. It > would cause a compile error because its arguments are const > references. There must be something else going on. The problem is that the operator* was relying on the target being separate memory. You changed it on the presumption that update in place would work, which it doesn't (because matrix multiply permutes the elements). Just take note, it caused a bug in inkscape which took quite a while to find. njh 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20091003 23:56:21

W dniu 4 października 2009 00:12 użytkownik njh <njh@...> napisał: > afaict, you changed the multiply from the c = a*b form to a *= b, which > broken it. The helper is implemented as follows: Matrix operator*(Matrix const &a, Matrix const &b) { Matrix temp(a); temp *= b; return b; } The breakage is rather weird. operator* cannot overwrite anything. It would cause a compile error because its arguments are const references. There must be something else going on. > So now we compute c = a*b; a = c, then use boost to compute d = > a; d *= b. Which seems roundabout and perhaps inefficient? The helpers use NRVO, so the performance hit shouldn't be big, but now that I look at this using the helper in this specific case is suboptimal. I'll fix this tomorrow. Regards, Krzysztof 
From: njh <njh@nj...>  20091003 23:13:39

On Sun, 4 Oct 2009, [UTF8] Krzysztof Kosi?ski wrote: >> tweenk added some boost stuff which generates the * operators from the *= >> operator. I'm now unconvinced of the merit of the idea, but it seemed >> good when first implemented. > > Sorry for the delayed reply. It is still possible to do M1 = M2 * M3 > (if it's not, there is a bug), where M1 and M2 can be any transform or > matrix type. I only replaced the boilerplate implementation with the > Boost operator helper. afaict, you changed the multiply from the c = a*b form to a *= b, which broken it. So now we compute c = a*b; a = c, then use boost to compute d = a; d *= b. Which seems roundabout and perhaps inefficient? I have no issue with the metaprogrammingy stuff. njh 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20091003 22:49:43

2009/9/1 njh <njh@...>: > On Tue, 1 Sep 2009 J.B.C.Engelen@... wrote: > >> Ok, I just checked the code and found that M*M was recently changed, so >> it is ok in Inkscape. Pfewww....!! >> Also, operator* was changed to operator*=, does this mean it is no >> longer possible to do M1 = M2 * M3 ? Or how does the compiler solve >> this? > > tweenk added some boost stuff which generates the * operators from the *= > operator. I'm now unconvinced of the merit of the idea, but it seemed > good when first implemented. Sorry for the delayed reply. It is still possible to do M1 = M2 * M3 (if it's not, there is a bug), where M1 and M2 can be any transform or matrix type. I only replaced the boilerplate implementation with the Boost operator helper. Pros: code for Matrix is not littered with lots of boilerplate operators; lower possibility of omissions. Cons: you need to read the boost operator helpers to know what the available operators are. (Fortunately the names are selfexplanatory.) I can add some comments to for Matrix that explains what operators are available and what the helpers do. Regards, Krzysztof 
From: J.B.C.E<ngelen@ew...>  20091003 15:36:33

The mail should have been titled "implicit moveto" instead of lineto... > Original Message > From: J.B.C.Engelen@... > [mailto:J.B.C.Engelen@...] > Sent: zaterdag 3 oktober 2009 17:29 > To: lib2geomdevel@... > Subject: [Lib2geomdevel] implicit lineto in svg path > > Hi all, > > I just modified our PathSink to accept the following: > "M 0,0 ... z L 1,1" > It should read the path as if it said > "M 0,0 ... z M0,0 L 1,1" > > In earlier discussions (subject "Path representation") I > spoke about there being a difference between these two, 2geom > currently did not even read the first one correctly. I am not > sure whether there is a difference at all between the two, so > I fixed 2geom to read the first as if it was the second. > > cheers, > Johan > >  >  > Come build with us! The BlackBerry® Developer Conference > in SF, CA is the only developer event you need to attend this > year. Jumpstart your developing skills, take BlackBerry > mobile applications to market and stay ahead of the curve. > Join us from November 912, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > 
From: J.B.C.E<ngelen@ew...>  20091003 15:28:56

Hi all, I just modified our PathSink to accept the following: "M 0,0 ... z L 1,1" It should read the path as if it said "M 0,0 ... z M0,0 L 1,1" In earlier discussions (subject "Path representation") I spoke about there being a difference between these two, 2geom currently did not even read the first one correctly. I am not sure whether there is a difference at all between the two, so I fixed 2geom to read the first as if it was the second. cheers, Johan 