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}
(6) 
_{Jun}
(16) 
_{Jul}
(25) 
_{Aug}
(16) 
_{Sep}
(3) 
_{Oct}

_{Nov}
(7) 
_{Dec}

2015 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(21) 
_{Apr}
(10) 
_{May}
(6) 
_{Jun}
(3) 
_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24
(1) 
25
(4) 
26

27

28

29

30
(3) 




From: Alvin Penner <penner@va...>  20101130 04:14:45

>we really want something like delx[1] = (x[3]x[0])/3; here. > >njh > sounds good to me, thanks, Alvin 
From: Dr Nathan Hurst <njh@nj...>  20101130 02:41:44

On Mon, Nov 29, 2010 at 07:03:23PM 0500, Alvin Penner wrote: > Have never posted to this list before, hope it arrives. It did so, thanks! > This is identical to the formula that is currently being used in the > routine sp_genericellipse_set_shape (src\spellipse.cpp) to render those > ellipses that have sodipodi attributes associated with them. > When applied to LP Bug 653315, file p.svg, this patch appears to resolve > the rendering problem shown there. Yes, the cubic fitting function uses geometric approximation as opposed to parametrix approximation. It is definitely better in this case, thanks for fixing, I'll commit to bzr when I get a chance. I'm not happy with the linear approximation  it contains a cusp at each endpoint and would be better replaced with equally spaced handles to give both geometric and parametric fitting. > else { // linear case > for (int i = 0; i < 2; ++i) { > delx[i] = 0; > dely[i] = 0; > } we really want something like delx[1] = (x[3]x[0])/3; here. njh 
From: Alvin Penner <penner@va...>  20101130 00:35:48

Hi, This is a followup to a thread at : https://sourceforge.net/mailarchive/forum.php?thread_name=30327020.post%40ta lk.nabble.com&forum_name=inkscapedevel Have never posted to this list before, hope it arrives. Attached is a modified version of the files src\2geom\sbasistobezier.cpp, and *.h. The original call to the routine : sbasis_to_bezier(bez, B, 4) has been replaced with a call to a new routine : sbasis_to_cubic_bezier(bez, B) in order to improve the conversion from sbasis to cubic bezier. In the original routine the cubic bezier was specified by fitting the four variables : dx/dt(0), dy/dt(0), dx/dt(1), dy/dt(1), where t is the independent variable in the parametric representation. In the new routine the bezier is specified by fitting the four variables dx/dy(0), dx/dy(1), x(0.5), y(0.5). Numerical tests have shown that the original routine, if applied to a circular arc, will yield a bezier curve whose control arms have a length d/r = theta/3 where d = Bezier control arm length r = radius theta = angle of arc. This is a correct zeroth order result for small theta, but is not appropriate for large theta. Numerical tests using the new routine on a circular arc yield a bezier control arm length that is consistent with d/r = 4*tan(theta/4)/3 This is identical to the formula that is currently being used in the routine sp_genericellipse_set_shape (src\spellipse.cpp) to render those ellipses that have sodipodi attributes associated with them. When applied to LP Bug 653315, file p.svg, this patch appears to resolve the rendering problem shown there. Alvin Penner 
From: <J.B.C.E<ngelen@ew...>  20101125 14:05:42

I suggest just replacing Inkscape's toSBasis with: D2<SBasis> EllipticalArc::toSBasis() const { D2<SBasis> arc; // the interval of parametrization has to be [0,1] Coord et = initialAngle().radians() + ( _sweep ? sweepAngle() : sweepAngle() ); Linear param(initialAngle(), et); Coord cos_rot_angle, sin_rot_angle; sincos(_rot_angle, sin_rot_angle, cos_rot_angle); // order = 4 seems to be enough to get a perfect looking elliptical arc SBasis arc_x = ray(X) * cos(param,4); SBasis arc_y = ray(Y) * sin(param,4); arc[0] = arc_x * cos_rot_angle  arc_y * sin_rot_angle + Linear(center(X),center(X)); arc[1] = arc_x * sin_rot_angle + arc_y * cos_rot_angle + Linear(center(Y),center(Y)); // ensure that endpoints remain exact for ( int d = 0 ; d < 2 ; d++ ) { arc[d][0][0] = initialPoint()[d]; arc[d][0][1] = finalPoint()[d]; } return arc; } Does that solve the continuity error? Johan > Original Message > From: Jasper van de Gronde [mailto:th.v.d.gronde@...] > Sent: Thursday, November 25, 2010 11:22 > To: Engelen, J.B.C. (Johan) > Cc: njh@...; lib2geomdevel@... > Subject: Re: [Lib2geomdevel] Continuity error > > On 20101125 09:48, J.B.C.Engelen@... wrote: > > ... > > I see you get the exception when doing a transform. What I think is > > causing the problem is D2<SBasis> EllipticalArc::toSBasis(). This > > method does *not* directly use the start and endpoints and > hence may > > cause the kind of trouble Nathan wrote. If you can rewrite the > > toSBasis method to ... in fact, this has been done already in 2geom > > branch! (so now I am assuming you are using Inkscape's copy > of 2geom) > > > > Try again with an updated version of toSBasis. > >... > > I now get errors complaining that Path::Elem does not exist > (and indeed, it doesn't, I've grepped the source and as far > as I can tell it's never defined). Admittedly I am cutting > corners a bit in terms of building (no cmake), but is this > really due to some cmake magic, or am I doing something else wrong? > 
From: Jasper van de Gronde <th.gronde@hc...>  20101125 10:21:46

On 20101125 09:48, J.B.C.Engelen@... wrote: > ... > I see you get the exception when doing a transform. What I think is > causing the problem is D2<SBasis> EllipticalArc::toSBasis(). This > method does *not* directly use the start and endpoints and hence may > cause the kind of trouble Nathan wrote. If you can rewrite the toSBasis > method to ... in fact, this has been done already in 2geom branch! (so > now I am assuming you are using Inkscape's copy of 2geom) > > Try again with an updated version of toSBasis. >... I now get errors complaining that Path::Elem does not exist (and indeed, it doesn't, I've grepped the source and as far as I can tell it's never defined). Admittedly I am cutting corners a bit in terms of building (no cmake), but is this really due to some cmake magic, or am I doing something else wrong? 
From: <J.B.C.E<ngelen@ew...>  20101125 08:48:14

The arc's initial point is explicitly set to the final point of the previous segment, and not changed after (same for the last appended linesegment). So I think it cannot be a problem with that. > c) come up with a better representation for arcs with direct > specification of endpoints (I've wasted a lot of time on this > one without any definitive solution  the closest I've got is > to use a NURBS, but they are ugly in a whole slew of ways). To me it seems this is done in 2geom: elliptical arcs' endpoints are directly defined and set in stone. I see you get the exception when doing a transform. What I think is causing the problem is D2<SBasis> EllipticalArc::toSBasis(). This method does *not* directly use the start and endpoints and hence may cause the kind of trouble Nathan wrote. If you can rewrite the toSBasis method to ... in fact, this has been done already in 2geom branch! (so now I am assuming you are using Inkscape's copy of 2geom) Try again with an updated version of toSBasis. After 0.48.1 is released, we really should update Inkscape's copy of 2geom ASAP. Ciao, Johan > Original Message > From: Dr Nathan Hurst [mailto:njh@...] > Sent: Thursday, November 25, 2010 01:14 > To: Jasper van de Gronde > Cc: lib2geomdevel@... > Subject: Re: [Lib2geomdevel] Continuity error > > On Wed, Nov 24, 2010 at 02:27:59PM +0100, Jasper van de Gronde wrote: > > Hi, > > > > If I construct a path like this (slightly simplified): > >  > > r = 100, width = 2*(r+16) > > path.start(Geom::Point(16,16)); > > path.appendNew<Geom::EllipticalArc> > > (r,r,0.0,false,false,Geom::Point(width16,16)); > > path.appendNew<Geom::LineSegment>(Geom::Point(16,16)); > >  > > I get plagued by: > >  > > terminate called after throwing an instance of > 'Geom::ContinuityError' > > what(): lib2geom exception: Noncontiguous path > > (2geom/path.cpp:97) > >  > > Any ideas what I'm doing wrong? > > > You aren't doing anything wrong, the problem is the arc > interface makes it very hard to precisely specify endpoints > (you are relying on cos/sin(x)*r = {1,0,1}*r, which is not > actually true for some choices of x in k*M_PI/2. For example: > >>> import math > >>> math.sin(math.pi) > 1.2246467991473532e16 > > (it should be 0). 2geom is very fussy about exactness which > is causing this error. There are several possible solutions: > a) move the end points of the line segments to match those of the arc > b) add stitch segments to join the line to the arc > c) come up with a better representation for arcs with direct > specification of endpoints (I've wasted a lot of time on this > one without any definitive solution  the closest I've got is > to use a NURBS, but they are ugly in a whole slew of ways). > > d) change policy about noncontinuity in paths. > e) something else :) > > njh 
From: Dr Nathan Hurst <njh@nj...>  20101125 00:13:51

On Wed, Nov 24, 2010 at 02:27:59PM +0100, Jasper van de Gronde wrote: > Hi, > > If I construct a path like this (slightly simplified): >  > r = 100, width = 2*(r+16) > path.start(Geom::Point(16,16)); > path.appendNew<Geom::EllipticalArc> > (r,r,0.0,false,false,Geom::Point(width16,16)); > path.appendNew<Geom::LineSegment>(Geom::Point(16,16)); >  > I get plagued by: >  > terminate called after throwing an instance of 'Geom::ContinuityError' > what(): lib2geom exception: Noncontiguous path (2geom/path.cpp:97) >  > Any ideas what I'm doing wrong? You aren't doing anything wrong, the problem is the arc interface makes it very hard to precisely specify endpoints (you are relying on cos/sin(x)*r = {1,0,1}*r, which is not actually true for some choices of x in k*M_PI/2. For example: >>> import math >>> math.sin(math.pi) 1.2246467991473532e16 (it should be 0). 2geom is very fussy about exactness which is causing this error. There are several possible solutions: a) move the end points of the line segments to match those of the arc b) add stitch segments to join the line to the arc c) come up with a better representation for arcs with direct specification of endpoints (I've wasted a lot of time on this one without any definitive solution  the closest I've got is to use a NURBS, but they are ugly in a whole slew of ways). d) change policy about noncontinuity in paths. e) something else :) njh 
From: Jasper van de Gronde <th.gronde@hc...>  20101124 13:28:13

Hi, If I construct a path like this (slightly simplified):  r = 100, width = 2*(r+16) path.start(Geom::Point(16,16)); path.appendNew<Geom::EllipticalArc> (r,r,0.0,false,false,Geom::Point(width16,16)); path.appendNew<Geom::LineSegment>(Geom::Point(16,16));  I get plagued by:  terminate called after throwing an instance of 'Geom::ContinuityError' what(): lib2geom exception: Noncontiguous path (2geom/path.cpp:97)  Any ideas what I'm doing wrong? (Note that in my application it's not terribly important whether the path is closed or not, but I have tried it, didn't make any difference.) I have managed to make the error go away in one specific configuration of coordinates, but it seems a little weird that that matters.  Jasper 