Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/17 DJ Delorie : > >> What is the transform between the numbers in the .pcb file and the >> actual representation on the board? > > Angle first, then stretch. There must be something more to it. Attached are two hand edited drawings where the first one has no stretching, e.g Radius=Width=Height The second one is the same drawing but with two of the arcs stretched. Notate that both start and end points have moved. Another point is that I cant find them, e.g Ctrl+R gives no hit. > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > stretched-arc-1.pcb Description: application/pcb-layout stretched-arc-2.pcb Description: application/pcb-layout ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Sat, 2011-07-16 at 19:16 +0200, Karl Hammar wrote: > Stefan Salewski: > > http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf > > It seems a little too general and it is a 35MB download [1]. > Their code seems to be in > > LibMathematics/Intersection/Wm5IntrEllipse2Ellipse2.cpp > > and at a quick glance it seems to be a lot of calculations. > > Do you have any experience about their library ? > > Regards, > /Karl Hammar > I am using their solution for "Distance point to line segment", it is fine. Many other sources, as the mathematica site, confuses it with the simpler solution for an infinite line. But I was in need for distance to finite line segment -- and I was not smart enough to find that simple solution myself. Of course math for ellipses is more difficult, but I think the www.geometrictools.com page is really nice, I have bookmarked it. But I have not looked at their ellipses code. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
> What is the transform between the numbers in the .pcb file and the > actual representation on the board? Angle first, then stretch. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 DJ Delorie : > >> It would be good if someone could tell me how the arc parameters >> are created and how they are used. > > Edit the *.pcb file manually. OK, but that means I need to understand how the drawing mechanism interprets ther numbers. Currently with the stretched arcs you presented the 45 deg Delta in the file is not what is drawn. What is the transform between the numbers in the .pcb file and the actual representation on the board? > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
> It would be good if someone could tell me how the arc parameters > are created and how they are used. Edit the *.pcb file manually. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 DJ Delorie : > > My quick take on this: > > Do the math based on a zero-thickness arc, then offset the resulting > distance by the arc half-thickness. > > I think this is more in line with how we *draw* the arcs. I have not yet investigated on how the arcs are draw nor how they are beeing stretched. For the moment I have given up on the algebraic solution but will do some more investigations even if it is fruitless. It would be good if someone could tell me how the arc parameters are created and how they are used. For the moment I have not found a way to stretch them and if the rule is to use data in the .pcb file as true source even if the limiting angles are wrong for the (unknown how the have been created) stretched arc one need to understand the interpretation of the attributes DJ's stretched arc example had different height,width in the file but a ctrl+R did not reflect this. > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Stefan Salewski: > http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf It seems a little too general and it is a 35MB download [1]. Their code seems to be in LibMathematics/Intersection/Wm5IntrEllipse2Ellipse2.cpp and at a quick glance it seems to be a lot of calculations. Do you have any experience about their library ? Regards, /Karl Hammar [1] http://www.geometrictools.com/Downloads/WildMagic5p5.zip --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
My quick take on this: Do the math based on a zero-thickness arc, then offset the resulting distance by the arc half-thickness. I think this is more in line with how we *draw* the arcs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Sat, 2011-07-16 at 00:18 -0700, Andrew Poelstra wrote: > > There is a fairly informative discussion of this problem on SO: > http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle > Or you may look at http://www.geometrictools.com/Documentation/Documentation.html http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 Karl Hammar : > Because of false assumptions about the "inner" and "outer" arcs, see > below. Ahhaaa, I stand corrected, assumptions is never ever good and it should have been obvious when making the thickness large, e.g if as large as the short axis it would generate a inner 'not ellipse' with short axis equal to 0. Sorry for my noise, I only did some simple checks with small thickness and did not go all the way. > If this error is small enougth to ignore, fine, but what error do we > tolerate? > > Regards, > /Karl Hammar > > [1] > http://de.wikipedia.org/wiki/Ellipse#Normalengleichung_.28kartesische_Koordinaten.29 > > --- > Aspö Data > Lilla Aspö 148 > S-742 94 Östhammar > Sweden > +46 173 140 57 > > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Igor Lopez: > 2011/7/16 Andrew Poelstra : > > There is a fairly informative discussion of this problem on SO: > > http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle > > I had a look and found one algebraic solution close to the one I have > proposed. > > > The correct methods given there generally require root-solvers, > > Why is the algebraic solution not correct? Because of false assumptions about the "inner" and "outer" arcs, see below. > > Since we rarely care about the exact distance, only "is it between > > 0 and Radius" it is probable that we could use a bisection method > > with very few iterations to get an answer. > > I am convinced we do not need any iterations or equation solvers. > We just need to check with the transformed point coordinates > in the equations for the two arcs where one is the inner arc and > the other is the outer arc where the point radius has been subtrcacted > respectively added to the arc lenghts(width, height). > If the point intersects the equation for the inner arc is <= 0 and > the equation for the outer arc is >= 0 and since it is not a complete > ellipse one need to check that the angle between point and > arc centerpoint is within the arcs limiting angles which is not > to difficult if the limiting angles are known. You are assuming that the two arcs are ellipses, which they are not. E.g. if you draw an ellipse with a thick pen, the inner space will look more like an almond than an ellipse. Take an ellipse with a = 5 and b = 4, and add a thickness = 1 to the perimeter. The point Pb = (xb,yb) = (3, 16/5) = (3, 3.2) is on the ellipse. Go out 1 (thickness) from that point in the normal direction (see e.g. [1]), i.e. along the line y - 16/5 = mn * (x - 3), mn = a*a*yb / (b*b*xb) = (25*16/5) / (16*3) = 5/3 you will come to the point Pt = (xt, yt) = (3+3/k, 16/5 + 5/k) ~= (3.51, 4.06) where k = sqrt(34), 5.83 < k < 5.84 Now, check if Pt lies on the ellipse: x^2/at^2 + y^2/bt^2 = 1, where at = a+1 = 6, bt = b+1 = 5 (3+3/k)^2 / 36 + (16/5+5/k)^2 / 25 ~= 1.0016 > 1 i.e. the new arc is not an ellipse. /// If this error is small enougth to ignore, fine, but what error do we tolerate? Regards, /Karl Hammar [1] http://de.wikipedia.org/wiki/Ellipse#Normalengleichung_.28kartesische_Koordinaten.29 --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 Andrew Poelstra : > There is a fairly informative discussion of this problem on SO: > http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle I had a look and found one algebraic solution close to the one I have proposed. > The correct methods given there generally require root-solvers, Why is the algebraic solution not correct? > Since we rarely care about the exact distance, only "is it between > 0 and Radius" it is probable that we could use a bisection method > with very few iterations to get an answer. I am convinced we do not need any iterations or equation solvers. We just need to check with the transformed point coordinates in the equations for the two arcs where one is the inner arc and the other is the outer arc where the point radius has been subtrcacted respectively added to the arc lenghts(width, height). If the point intersects the equation for the inner arc is <= 0 and the equation for the outer arc is >= 0 and since it is not a complete ellipse one need to check that the angle between point and arc centerpoint is within the arcs limiting angles which is not to difficult if the limiting angles are known. >> > Restricting this to an ellipse /segment/ is tricky, since as DJ >> > pointed out, these are not "real" elliptical arcs, but stretched >> > arcs, so the limiting angles do not correspond directly to actual >> > angles. This is the true problem, if the limiting angles are not know then the problem is unsolvable but I assume there is a way of finding what the real limiting angles are. I have not looked into how they become stretched but there must be a systematic way the stretch transforms the arc. >> >> Isn't that a bug to be fixed instead? >> > > It's a design flaw, but "fixing" it would break existing designs. Well, one could still keep the (wrong when stretched) limiting angles and add new paramters to the struct for real angles. Now I also assume from looking at DJ's stretched arc that the axis length along the not stretched direction must also be recalculated. I'll be back. > > -- > Andrew Poelstra > Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew/ > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Fri, Jul 15, 2011 at 09:45:42PM +0200, Karl Hammar wrote: > Andrew Poelstra: > > I am using the polar form of the ellipse given at: > > > > http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center > > > > with theta the angle of the point we are checking. (Those cos > > and sin calculations are easy, just delta-x/len and delta-y/len.) > > With that I can calculate the distance from the point to an > > ellipse. > > The shortest line from (x,y) to the ellipse goes through the normal to > the ellipses perimeter. > Ohh... of course. Darn. > The normal does not generally go through the middlepoint of the ellipse. > It crosses the line between the center and the nearest focal point. > > What you get with the above polar calculation is a little bigger value > than the true distance, but it could serve as a first aproximation. > You could take the minimum of the polar form through the center and > through the focus, to get a better value. > > How accurate an value do we need, would minimum of ±5% and ±0.1mm > be ok ? > I suspect that determining an error bound on my method would be just as difficult (mathematically) as finding a different method. There is a fairly informative discussion of this problem on SO: http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle The correct methods given there generally require root-solvers, and I don't think we have one right now. We could throw one together or introduce a dependency on, say, the GNU Scientific Library. Since we rarely care about the exact distance, only "is it between 0 and Radius" it is probable that we could use a bisection method with very few iterations to get an answer. > > Restricting this to an ellipse /segment/ is tricky, since as DJ > > pointed out, these are not "real" elliptical arcs, but stretched > > arcs, so the limiting angles do not correspond directly to actual > > angles. > ... > > Isn't that a bug to be fixed instead? > It's a design flaw, but "fixing" it would break existing designs. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra: > I am using the polar form of the ellipse given at: > > http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center > > with theta the angle of the point we are checking. (Those cos > and sin calculations are easy, just delta-x/len and delta-y/len.) > With that I can calculate the distance from the point to an > ellipse. The shortest line from (x,y) to the ellipse goes through the normal to the ellipses perimeter. The normal does not generally go through the middlepoint of the ellipse. It crosses the line between the center and the nearest focal point. What you get with the above polar calculation is a little bigger value than the true distance, but it could serve as a first aproximation. You could take the minimum of the polar form through the center and through the focus, to get a better value. How accurate an value do we need, would minimum of ±5% and ±0.1mm be ok ? > Restricting this to an ellipse /segment/ is tricky, since as DJ > pointed out, these are not "real" elliptical arcs, but stretched > arcs, so the limiting angles do not correspond directly to actual > angles. ... Isn't that a bug to be fixed instead? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
I am using the polar form of the ellipse given at: http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center with theta the angle of the point we are checking. (Those cos and sin calculations are easy, just delta-x/len and delta-y/len.) With that I can calculate the distance from the point to an ellipse. Restricting this to an ellipse /segment/ is tricky, since as DJ pointed out, these are not "real" elliptical arcs, but stretched arcs, so the limiting angles do not correspond directly to actual angles. Adding explicit checks for distance from endpoints would give us an almost-correct solution. There are still pathologies I can think of with arcs whose thickness (or thickness + search radius) is greater than the minor axis, though.. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Ethan Swint: > On 07/14/2011 11:23 PM, Andrew Poelstra wrote: ... > > To do either one analytically looks like a 4th order > > equation must be solved. So I am looking for cheap > > iterative solutions, or approximations, instead. > > If the point is within the arc's bounding box, transform the point's > global coordinates into the arc's local (x: major axis, y: minor axis) > coordinates. Ack. > Then the distance calculation is a no-brainer. Could you then show us the formula please ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra: > On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote: ... > > Why not just give a warning if width and height is not equal, saying > > that we don't really support ellipses for the moment, and be done with > > it. > I could, I suppose, but as you mentioned in another post, there > are muddled physical units. As that is what I am trying to fix, > I need to make changes anyway. Ok. > It would be nice if we could at least support the featureset of > our file format, while I'm at it. I found in [1]: Given an ellipse: x^2 / a^2 + y^2 / b^2 = 1 where a = greater semiaxis b = lesser semiaxis a >= b > 0 e = sqrt( a^2 + b^2 ) = linear excentricity = focalpoint semidistance epsilon = e / a = numerical excentricity The equation of the normal to the ellipse: y - y1 = mn * (x - x1), where mn = (a*a * y1) / (b*b * x1) the point on the ellipse = (x1, y1) point on normal = (x, y) The length of the normal (to where it crosses the x-axis): n = b * sqrt(a*a*a*a - e*e * x1*x1) / (a*a) The length of the subnormal (as above but along the x-axis): sn = abs( b*b * x1 / (a*a) ) Hope that it helps. We're here if you need more help. Regards, /Karl Hammar [1] Mathematische formeln Dipl.-Ing. Hans-Jochen Bartsch Veb Fachbuschverlag Leipzig 1974 --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On 07/14/2011 11:23 PM, Andrew Poelstra wrote: On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: Check if point px,py is on rotaded elliptic arc: 1) Translate point to use ellipse center as origin, Px = px-x Py = py-y 2) Insert Px, Py in Eq1 lval equal 0 -> point is exactly on arc lval above zero -> point is inside arc lval below zero -> point is outside arc The problem here is that the elliptical arc has nonzero thickness (usually, if it is a drawn solder arc). So I actually need to see if the point is /within a certain radius/ of the arc. For that I need the distance from the point to the arc, or to draw a circle around the point and check if that intersects the arc. To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. If the point is within the arc's bounding box, transform the point's global coordinates into the arc's local (x: major axis, y: minor axis) coordinates. Then the distance calculation is a no-brainer. -Ethan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Jul 14, 2011, at 1:09 PM, DJ Delorie wrote: > >> The linear "stretching" transformation (x', y') = (a*x, b*y) applied >> to a circle yields an ellipse whose axes are parallel to the >> coordinate axes. > > Yes, *unless* you're including the start/end angles in that > transformation, instead of applying them afterwards. > > http://www.delorie.com/pcb/tmp/stretched-arc.pcb > > This shows two 45-degree Arcs. One has width==height, the other does > not. Note that the end angle on the stretched arc is 45, but the > arc does not end at the 45 degree marker. Linear stretching doesn't generally preserve angles. Still, the result of stretching a circle is an ellipse. Indeed, the more general statement that stretching an ellipse *in any direction* yields an ellipse is true. Since stretching does not preserve angles, the operation of selecting an arc from an ellipse by angle does not commute with stretching. Thus, your example. This is closely related to math that confused the great genius Johannes Kepler for quite a while. We're still somewhat burdened by artifacts of his path to understanding: look up "eccentric anomaly" sometime. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Igor: > 2011/7/14 Karl Hammar : > > Looking at pcb.pdf, page 64, section 8.8.1 Arc... ... > > And there is no way to specify a "slanted" ellipse in the file format > > either, so if we really want ellipses, the file format is incomplete > > and should be changed. > > > > Why not just give a warning if width and height is not equal, saying > > that we don't really support ellipses for the moment, and be done with > > it. ... > I just liked the challenge with rotated ellipses especially checking for > intersection between them. Well, one could add a int slant = 0; // TODO: add support for rotated ellipses and start debugging. Or why not add full support for slantet/rotated ellipses. It would affect documentation (file format), gui, src/search.c and possible other places. In your code, you translate to ellipse center, why not rotate so the ellipse is with the foci on the x-axis, wouldn't that make the calc. easier? You already have the a/b ((semi-)width/height above) and the slant (or what should we call the ellipse rotation), so it is only the test point (X,Y) we are rotating, and the ellipse would then be in the normal form (simpler to visualize), one could also mirror the system so X and Y > 0: x^2/a^2 + y^2/b^2 = 1, a >= b > 0 with foci at (0,c) and (0,-c) where c = sqrt(a^2 - b^2) One could possible use: . a normal to the ellipse bisects the rays from the foci . if P = (x,y) is on the perimeter, x > 0, y > 0 F = (0,c) a focus Q = (a/e, y), where e = c/a, y = the y of P then PF / PQ = e, PF = length P to F, dito. PQ /// And while we are at it, shouldn't we use a sane geometry where positive y's are up and zero angle is alinged with positive x-axis... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
> The linear "stretching" transformation (x', y') = (a*x, b*y) applied > to a circle yields an ellipse whose axes are parallel to the > coordinate axes. Yes, *unless* you're including the start/end angles in that transformation, instead of applying them afterwards. http://www.delorie.com/pcb/tmp/stretched-arc.pcb This shows two 45-degree Arcs. One has width==height, the other does not. Note that the end angle on the stretched arc is 45, but the arc does not end at the 45 degree marker. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Jul 14, 2011, at 12:00 PM, DJ Delorie wrote: > Technically, what we have is *not* an ellipse - it's a stretched arc. ? The linear "stretching" transformation (x', y') = (a*x, b*y) applied to a circle yields an ellipse whose axes are parallel to the coordinate axes. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
> According to the manual ( I just checked) Arc is just a quarter > circle even though it is overspecified in terms of parameters. > Ellipses are not mentioned. Technically, what we have is *not* an ellipse - it's a stretched arc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/14 Karl Hammar : > Looking at pcb.pdf, page 64, section 8.8.1 Arc... > > Andrew Poelstra: > ... >> If you have a full ellipse, then Width and Height are exactly >> what they sound like -- the full length from one side of the >> ellipse to the other. > > The file format specifies it as: > > Width Height > The width and height, from the center to the edge. ... > > Are you saying that the parser etc. is doubling it? > >> There is no way right now to rotate the ellipse, so alpha >> from the site you cited is always 0. > ... > > And there is no way to specify a "slanted" ellipse in the file format > either, so if we really want ellipses, the file format is incomplete > and should be changed. > > Why not just give a warning if width and height is not equal, saying > that we don't really support ellipses for the moment, and be done with > it. Sorry for the noise. According to the manual ( I just checked) Arc is just a quarter circle even though it is overspecified in terms of parameters. Ellipses are not mentioned. I just liked the challenge with rotated ellipses especially checking for intersection between them. > Regards, > /Karl Hammar > > --- > Aspö Data > Lilla Aspö 148 > S-742 94 Östhammar > Sweden > +46 173 140 57 > > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote: > Looking at pcb.pdf, page 64, section 8.8.1 Arc... > > Andrew Poelstra: > ... > > If you have a full ellipse, then Width and Height are exactly > > what they sound like -- the full length from one side of the > > ellipse to the other. > > The file format specifies it as: > > Width Height >The width and height, from the center to the edge. ... > > Are you saying that the parser etc. is doubling it? > Oh, my bad! I had checked manually what it did yesterday, and misremembered the behavior. You are right, Width and Height are the distance from the center to the edge. > > There is no way right now to rotate the ellipse, so alpha > > from the site you cited is always 0. > ... > > And there is no way to specify a "slanted" ellipse in the file format > either, so if we really want ellipses, the file format is incomplete > and should be changed. > > Why not just give a warning if width and height is not equal, saying > that we don't really support ellipses for the moment, and be done with > it. > I could, I suppose, but as you mentioned in another post, there are muddled physical units. As that is what I am trying to fix, I need to make changes anyway. It would be nice if we could at least support the featureset of our file format, while I'm at it. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Looking at pcb.pdf, page 64, section 8.8.1 Arc... Andrew Poelstra: ... > If you have a full ellipse, then Width and Height are exactly > what they sound like -- the full length from one side of the > ellipse to the other. The file format specifies it as: Width Height The width and height, from the center to the edge. ... Are you saying that the parser etc. is doubling it? > There is no way right now to rotate the ellipse, so alpha > from the site you cited is always 0. ... And there is no way to specify a "slanted" ellipse in the file format either, so if we really want ellipses, the file format is incomplete and should be changed. Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/15 Andrew Poelstra : > On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote: >> I had a quick look at the routine and must say that I did not grasp >> the code. It is probably due to some heavy optimizations. >> > > Heavy optimizations, perhap, but also because it is wrong. > > > If you have a full ellipse, then Width and Height are exactly > what they sound like -- the full length from one side of the > ellipse to the other. > > There is no way right now to rotate the ellipse, so alpha > from the site you cited is always 0. > > > However, an arc is only a SEGMENT of the ellipse. The segment > starts at startAngle degrees and continuse for deltaAngle > degrees counterclockwise. Your code assumes we have a full > ellipse to intersect with. > Ok now I understand. This means that the requirement for intersecting needs to be expanded to check that the angle from arc centerpoint to the point is within the arc segment as well. The end edges is a little bit tricky due to the rounded corner from the point radius but a simplification can be made by reducing the startAngle and increasing the deltaAngle as function of point radius and arc height, width. The equations must still hold independent if it is just a section of the ellipse. No need for an iterative or aproximate solution when point is a circle. It becomes very easy if the point has no extension, e.g radius = 0. In my equations I do have taken into account rotated arcs. > -- > Andrew Poelstra > Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew/ > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote: > I had a quick look at the routine and must say that I did not grasp > the code. It is probably due to some heavy optimizations. > Heavy optimizations, perhap, but also because it is wrong. If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. However, an arc is only a SEGMENT of the ellipse. The segment starts at startAngle degrees and continuse for deltaAngle degrees counterclockwise. Your code assumes we have a full ellipse to intersect with. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/15 Andrew Poelstra : > On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: >> >> Check if point px,py is on rotaded elliptic arc: >> 1) Translate point to use ellipse center as origin, >> Px = px-x >> Py = py-y >> 2) Insert Px, Py in Eq1 >> lval equal 0 -> point is exactly on arc >> lval above zero -> point is inside arc >> lval below zero -> point is outside arc >> > > The problem here is that the elliptical arc has nonzero > thickness (usually, if it is a drawn solder arc). So I > actually need to see if the point is /within a certain > radius/ of the arc. > > For that I need the distance from the point to the arc, > or to draw a circle around the point and check if that > intersects the arc. That is why I proposed two equations, one for the inner arc and one for the outer arc. Add resp Subtract half the arc thickness in the expression for the equations parameters and if the point has a radius one needs to add resp subtract that as well. With this approach it is rather simple to check if the point intersects the arc by evaluating the left side values of both equations. The point will intersect if the left hand value for the small arc is below or equal to zero and if the left hand value for the larger arc is above or equal to zero. It is an order of magnitude more difficult if the point is not a circle. I will have a look at the code for arc intersecting with another arc but I guess it will be rather more complicted. > To do either one analytically looks like a 4th order > equation must be solved. So I am looking for cheap > iterative solutions, or approximations, instead. > > -- > Andrew Poelstra > Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew/ > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 01:24:45PM +0200, Karl Hammar wrote:
> Andrew Poelstra:
> > On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> > > Mark Rages wrote:
> > > > Stretched arcs are a misfeature. Can they be deprecated?
> ...
> > The reason I bring this up is that the IsPointOnArc() in search.c
> > assumes a circular arc right now. ("Distance from elliptical arc
> > segment" is quite a tricky computational problem.)
>
> There is some (physical) dimesion awkwardnesses going on in this
> routine:
>
I am trying to avoid square units entirely and just use the
Distance() function from misc.c instead. Maybe the function
call is too expensive, but testing will tell us that.
Certainly I see no reason that squaring should be cheaper
than sqrt, which is the tradeoff made all over the code.
In addition to the unit awkwardness, I am also trying to
clear up the micro-optimizations that assume a specific
architecture and ancient compiler.
--
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew/
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: > > Check if point px,py is on rotaded elliptic arc: > 1) Translate point to use ellipse center as origin, > Px = px-x > Py = py-y > 2) Insert Px, Py in Eq1 > lval equal 0 -> point is exactly on arc > lval above zero -> point is inside arc > lval below zero -> point is outside arc > The problem here is that the elliptical arc has nonzero thickness (usually, if it is a drawn solder arc). So I actually need to see if the point is /within a certain radius/ of the arc. For that I need the distance from the point to the arc, or to draw a circle around the point and check if that intersects the arc. To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
I had a quick look at the routine and must say that I did not grasp the code.
It is probably due to some heavy optimizations.
My approach had been more in the line of:
// Assumption done on ArcType in that the StartAngle attribute is the
// arcs CCW rotation with zero meaning that attribute Width is along X
// and attribute Height is along Y
bool IsPointOnArc (float X, float Y, float Radius, ArcTypePtr Arc)
// Point is defined as a circle loctaed at X,Y with radius Radius
{
double pdx, pdx2, pdy, pdy2, cosAlpha, sinAlpha, al2, as2, bl2, bs2;
double Al, As, Bl, Bs, Cl, Cs; // Should be part of ARC struct and
updated accordingly.
double resSmall, resLarge;
// Translate point coordinates to local arc origin
pdx = X - Arc->X;
pdx2 = pdx*pdx;
pdy = Y - Arc->Y;
pdy2 = pdy*pdy;
// This could have been optimized if Al, As, Bl, Bs, Cl and Cs was
part of the Arc and only
// updated when needed, e.g at creation of ARC or modification of ARC.
// Note to myself, since the larger and smaller ellipses is a
function of the Radius it will not
// work unless the ARC had a memory with respect to which radius
have been used earlier, e.g let
// the ARC worry about how/when to calculate these values.
// Note this whole procedure is based on the equation governing a
rotated ellipse, see:
// http://www.maa.org/joma/Volume8/Kalman/General.html
// Here we calculate the two boundary ellipses, one on the inside
(As, Bs, Cs) and one on the outside
// (Al, Bl, Cl) where the geometry is given by the ellipse Height,
Width and its thickness.
// The radius of the point is added to the boundary in order to use
the point coordinates
// in the equations.
// Generally the eq is: 1-Ax²+Bx*y+C*x²= 0 and a given points
coordinates will result in the lVal
// > 0 for inside the ellipse,
// = 0 for on the ellipse
// < 0 for outside the ellipse
cosAlpha=cos(Arc->StartAngle*M_PI/180);
sinAlpha=sin(Arc->StartAngle*M_PI/180);
al2 =
1/((Arc->Width+Arc->Thickness/2+Radius)*(Arc->Width+Arc->Thickness/2+Radius));
bl2 =
1/((Arc->Height+Arc->Thickness/2+Radius)*(Arc->Height+Arc->Thickness/2+Radius));
as2 =
1/((Arc->Width-Arc->Thickness/2-Radius)*(Arc->Width-Arc->Thickness/2-Radius));
bs2 =
1/((Arc->Height-Arc->Thickness/2-Radius)*(Arc->Height-Arc->Thickness/2-Radius));
Al = cosAlpha*cosAlpha*al2+sinAlpha*sinAlpha*bl2;
Bl = -2*cosAlpha*sinAlpha*(al2-bl2);
Cl = sinAlpha*sinAlpha*al2+cosAlpha*cosAlpha*bl2;
As = cosAlpha*cosAlpha*as2+sinAlpha*sinAlpha*bs2;
Bs = -2*cosAlpha*sinAlpha*(as2-bs2);
Cs = sinAlpha*sinAlpha*as2+cosAlpha*cosAlpha*bs2;
resSmall = 1-As*pdx2-Bs*pdx*pdy-Cs*pdy2;
resLarge = 1-Al*pdx2-Bl*pdx*pdy-Cl*pdy2;
// For point to be on arc -> outside the small ellipse and inside
the large ellipse
if((resSmall<=0) && (resLarge>=0))
return (true);
else
return (false);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra:
> On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> > Mark Rages wrote:
> > > Stretched arcs are a misfeature. Can they be deprecated?
...
> The reason I bring this up is that the IsPointOnArc() in search.c
> assumes a circular arc right now. ("Distance from elliptical arc
> segment" is quite a tricky computational problem.)
There is some (physical) dimesion awkwardnesses going on in this
routine:
IsPointOnArc (float X, float Y, float Radius, ArcTypePtr Arc)
{
A: double x, y, dx, dy, r1, r2, a, d, l;
double pdx, pdy;
double ang1, ang2, ang0, delta;
int startAngle, arcDelta;
pdx = X - Arc->X;
pdy = Y - Arc->Y;
B: l = pdx * pdx + pdy * pdy;
Radius += 0.5 * Arc->Thickness;
if (Radius < 0) /* thin arc: trivial condition */
return (false);
/* concentric arcs, simpler intersection conditions */
C: if (l < 0.5)
{
if (Arc->Width <= Radius)
return (true);
else
return (false);
}
Here r1, r2 have the dim. distance:
r1 = Arc->Width;
r2 = Radius;
if (sqrt (l) < r2 - r1) /* the arc merged in the circle */
return (true);
Here r1, r2 have the dim. distance squared:
r1 *= r1;
r2 *= r2;
a = 0.5 * (r1 - r2 + l) / l;
Here r1 becomes dimensionless:
r1 = r1 / l;
Please don't do things like that.
A, it's good to sort variables per dimension type because they
don't mix with each other using "+" or "-".
Here
x, y, dx, dy, pdx, pdy have dimension length or distance,
a and d are dimensionless,
l is distance squared, and
r1 and r2 varies.
If the intended (physical) dimension is unusual, it is good to show
it with a comment or using different types (as in typedef).
Also, it is good to use longer och more unique variable names if it's
scope is more than a few lines long. Searching for "x" is a pain.
B, if you use a variable "l" (as in length?) but it means distance^2,
call it l2, distance_squared or something to distinguish it from a
plain distance.
C, this seems to test if the
"distance between (X,Y) and center of arc" squared < 0.5, or
"distance between (X,Y) and center of arc" < sqrt(0.5) which is ~0.7.
Where do the 0.5 come from, and why are the circles concentric if they
passes this test, and if we actually are doing some miniature thing
here, this test will fail, or?
Attached patch corrects the r1/r2 weirdness, A, and B.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
diff --git a/src/search.c b/src/search.c
index 30fe883..518b56a 100644
--- a/src/search.c
+++ b/src/search.c
@@ -1042,61 +1042,53 @@ IsPointInBox (LocationType X, LocationType Y,
BoxTypePtr box, BDimension Radius)
bool
IsPointOnArc (float X, float Y, float Radius, ArcTypePtr Arc)
{
- double x, y, dx, dy, r1, r2, a, d, l;
double pdx, pdy;
+ double l2; // distance squared
+
+ // normal angles (one full turn is 360)
double ang1, ang2, ang0, delta;
int startAngle, arcDelta;
pdx = X - Arc->X;
pdy = Y - Arc->Y;
- l = pdx * pdx + pdy * pdy;
+ l2 = pdx * pdx + pdy * pdy;
Radius += 0.5 * Arc->Thickness;
if (Radius < 0) /* thin arc: trivial condition */
return (false);
/* concentric arcs, simpler intersection conditions */
- if (l < 0.5)
+ if (l2 < 0.5)
{
if (Arc->Width <= Radius)
return (true);
else
return (false);
}
- r1 = Arc->Width;
- r2 = Radius;
- if (sqrt (l) < r2 - r1) /* the arc merged in the circle */
+ if (sqrt (l2) < Radius - Arc->Width) /* the arc merged in the circle */
return (true);
- r1 *= r1;
- r2 *= r2;
- a = 0.5 * (r1 - r2 + l) / l;
- r1 = r1 / l;
- d = r1 - a * a;
- /* the circles are too far apart to touch or probably just touch */
- if (d < 0)
-return (false);
- /* project the points of intersection */
- d = sqrt (d);
- x = a * pdx;
- y = a * pdy;
- dy = -d * pdx;
- dx = d * pdy;
- /* arrgh! calculate the angles, and put them in a standard range */
- startAngle = Arc->StartAngle;
- arcDelta = Arc->Delta;
- if (arcDelta < 0)
-{
- startAngle += arcDelta;
- arcDelta = -arcDelta;
-}
- if (arcDelta > 360)
-arcDelta = 360;
- while (startAngle < 0)
-startAngle += 360;
- while (startAngle > 360)
-startAngle -= 360;
- ang1 = RAD_TO_DEG * atan2 ((y + dy), -(x + dx));
+
+ {
+double x, y, dx, dy, w2;
+double ka, kd; // dimensionless koefficients
+
+w2 = Arc->Width * Arc->Width;
+ka = 0.5 * (w2 - Radius * Radius + l2) / l2;
+kd = w2 / l2 - ka * ka;
+/* the circles are too far apart to touch or probably just touch */
+if (kd < 0)
+ return (false);
+kd = sqrt (kd);
+
+/* project the points of intersection */
+x = ka * pdx;
+y = ka * pdy;
+dy = -kd * pdx;
+dx = kd * pdy;
+ang1 = RAD_TO_DEG * atan2 ((y + dy), -(x + dx));
+ang2 = RAD_TO_DEG * atan2 ((y - dy), -(x
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/14 Andrew Poelstra :
> On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
>> On Wed, 13 Jul 2011 10:02:28 -0600
>> Mark Rages wrote:
>>
>> > Stretched arcs are a misfeature. Can they be deprecated?
>> >
>> > Otherwise, they are just another object that cannot be rotated at
>> > arbitrary angles.
>>
>> There is no inherent reason elliptical arcs cannot be rotated
>> arbitrarily. Any restriction on such rotation is simply due to
>> implementation faults in pcb.
>>
>
> The reason I bring this up is that the IsPointOnArc() in search.c
> assumes a circular arc right now. ("Distance from elliptical arc
> segment" is quite a tricky computational problem.)
>
> You can see this problem by drawing an stretched arc and trying
> to select and move it.
>
> Being a math major and all, you'd think I could fix this, but it
> eludes me...
>
Good page: http://www.maa.org/joma/Volume8/Kalman/General.html
CCW rotation through angle alpha will give the following equation
Eq1 : 1 - A*x² - B*x*y - C*y² = 0
where
A = cos(alpha)²/a²+sin(alpha)²/b²
B = 2*cos(alpha)*sin(alpha)*(1/a²-1/b²)
C = sin(alpha)²/a²+cos(alpha)²/b²
and a is half axis length along x in non rotated state and b is half
axis length along y in non rotated state.
The ellipse should have the attributes,
x centerpoint
y centerpoint
a half Axis length along X when non rotated
b half Axix length along y when non rotaded
alpha Rotation angle (in ccw direction)
maybe even the A,B and C so they are only calculated once.
Check if point px,py is on rotaded elliptic arc:
1) Translate point to use ellipse center as origin,
Px = px-x
Py = py-y
2) Insert Px, Py in Eq1
lval equal 0 -> point is exactly on arc
lval above zero -> point is inside arc
lval below zero -> point is outside arc
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> On Wed, 13 Jul 2011 10:02:28 -0600
> Mark Rages wrote:
>
> > Stretched arcs are a misfeature. Can they be deprecated?
> >
> > Otherwise, they are just another object that cannot be rotated at
> > arbitrary angles.
>
> There is no inherent reason elliptical arcs cannot be rotated
> arbitrarily. Any restriction on such rotation is simply due to
> implementation faults in pcb.
>
The reason I bring this up is that the IsPointOnArc() in search.c
assumes a circular arc right now. ("Distance from elliptical arc
segment" is quite a tricky computational problem.)
You can see this problem by drawing an stretched arc and trying
to select and move it.
Being a math major and all, you'd think I could fix this, but it
eludes me...
--
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew/
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, 13 Jul 2011 10:02:28 -0600 Mark Rages wrote: > Stretched arcs are a misfeature. Can they be deprecated? > > Otherwise, they are just another object that cannot be rotated at > arbitrary angles. There is no inherent reason elliptical arcs cannot be rotated arbitrarily. Any restriction on such rotation is simply due to implementation faults in pcb. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 10:02:28AM -0600, Mark Rages wrote: > > Stretched arcs are a misfeature. Can they be deprecated? > Why are they a misfeature? > Otherwise, they are just another object that cannot be rotated at > arbitrary angles. > That's a separate problem. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 5:46 AM, Kai-Martin Knaak wrote: > Andrew Poelstra wrote: > >> Arc[18 15 10 15 5 2000 90 90 "clearline"] >> >> will show the arc as a quarter-circle with GL enabled, even >> though it is actually taller than it is wide. > > confirm. > > PCB v20100929-2 as delivered by debian renders the stretched arc > correctly. > Stretched arcs are a misfeature. Can they be deprecated? Otherwise, they are just another object that cannot be rotated at arbitrary angles. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra wrote: > Arc[18 15 10 15 5 2000 90 90 "clearline"] > > will show the arc as a quarter-circle with GL enabled, even > though it is actually taller than it is wide. confirm. PCB v20100929-2 as delivered by debian renders the stretched arc correctly. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
