Re: gEDA-user: git HEAD PCB now supports user-defined holes in polygons
On Tue, 2010-06-08 at 00:57 +0200, kai-martin knaak wrote: > Peter Clifton wrote: > > > A subsequent commit also introduced a GUI tool for creating holes in > > polygons. Standard editing tools such as insert / move / remove point > > work on the holes too. > > Great! > Does this apply to solder stop, too? No, solder mask is always derived from pads - the holes thing was just about extending our support for polygon shapes to include user drawn holes. I appreciate it would be nice in the future to have the ability to override solder mask shapes and define things like text in the masks. (I've seen this used to good effect on boards with no silk-screen). Best wishes, Peter -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
On Tue, 2010-06-08 at 01:05 +0200, Krzysztof Kościuszkiewicz wrote:
> All,
>
> I have noticed two bugs with recent git versions of gl-enabled pcb
> (6507083b0401e0).
>
> 1) Garbage is displayed outside of board area.
Try this patch, and see if it changes the behaviour / helps / breaks
things further.
NB: Cursory playing suggests that my "master" branch (with pours)
doesn't work quite correctly with user-defined holes in polygons.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
diff --git a/src/hid/gtk/gui-output-events.c b/src/hid/gtk/gui-output-events.c
index 1fa2640..efce5ec 100644
--- a/src/hid/gtk/gui-output-events.c
+++ b/src/hid/gtk/gui-output-events.c
@@ -73,6 +73,7 @@ static GLfloat last_modelview_matrix[4][4] = {{1.0, 0.0, 0.0, 0.0},
{0.0, 0.0, 0.0, 1.0}};
static int global_view_2d = 1;
+static bool check_gl_drawing_ok_hack = false;
/* Set to true if cursor is currently in viewport. This is a hack to prevent
* Crosshair stack corruption due to unmatching window enter / leave events */
@@ -596,6 +597,9 @@ ghid_show_crosshair (gboolean show)
static GdkColor cross_color;
extern float global_depth;
+ if (!check_gl_drawing_ok_hack)
+return;
+
if (gport->x_crosshair < 0 || ghidgui->creating) {// || !gport->has_entered) {
printf ("Returning\n");
return;
@@ -1752,6 +1756,8 @@ ghid_port_drawing_area_expose_event_cb (GtkWidget * widget,
hidgl_init ();
+ check_gl_drawing_ok_hack = true;
+
/* If we don't have any stencil bits available,
we can't use the hidgl polygon drawing routine */
/* TODO: We could use the GLU tessellator though */
@@ -1974,6 +1980,8 @@ ghid_port_drawing_area_expose_event_cb (GtkWidget * widget,
else
glFlush ();
+ check_gl_drawing_ok_hack = false;
+
/* end drawing to current GL-context */
gdk_gl_drawable_gl_end (pGlDrawable);
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Next problem, PCB looses rats
On Mon, 2010-06-07 at 19:14 -0400, DJ Delorie wrote: > Do we use alt for anything else? Would alt-click interfere with > window managers? Metacity / compiz have that as a short-cut for dragging windows around. Compiz eats almost all the Meta + ... operations, along with Alt+Scroll, and various other combinations. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
On Tue, 2010-06-08 at 01:05 +0200, Krzysztof Kościuszkiewicz wrote:
> All,
>
> I have noticed two bugs with recent git versions of gl-enabled pcb
> (6507083b0401e0).
You're not only using the GL enabled version, but the "poured" region
enabled version. Beware - the behaviour with Polygons on that branch (my
"master" branch is not 100% compatible with stock git HEAD PCB)!
If you're not deliberately using the pour support, you might prefer my
"before_pours" branch, which does not change the semantics for polygon
handling.
(The semantics in the branch you have are that every diced piece of a
polygon is kept, but only those connected to something are retained.
Each diced piece acts separately as far as connectivity is concerned,
and can contribute to different connections.
> 1) Garbage is displayed outside of board area.
I'm not testing the pours branch ("master") as extensively as the
"before_pours" branch, so it is possible there is a bug affecting the
rendering there which I've not corrected. That said, the GL code is
mostly common to both ("master" sits on top of "before_pours").
What graphics card / driver are you using Radeon R300 + Mesa?
This bug is almost certainly going to turn out to be driver dependent.
Since you are using a mesa based driver, try with:
LIBGL_ALWAYS_SOFTWARE=1 pcb ...
and or
LIBGL_ALWAYS_INDIRECT=1 pcb ...
Does this change behaviour?
> 2) pcb sometimes segfaults in glEnable() during startup.
I'd need to see a backtrace of _which_ glEnable() call creates the
problem to be able to start thinking about why that might be..
> I'm using tiling WM and in some cases pcb segfaults during startup.
> I suspect this depends on the order of X events being sent to the
> application. Stack trace is attached. If needed I can do more
> debugging/build with debug libs, but I'm no X expert :)
You need more debug versions of libraries installed to flesh out the
backtrace, but I think I see which glEnable your segfault landed on:
glEnable (GL_COLOR_LOGIC_OP);
potentially (and perhaps consistent with other symptoms), this code is
being called outside of the correct GL rendering context being set up.
Apparently this doesn't cause problems on my Intel drivers, but is
almost certainly the wrong thing to do...
I'll see if I can hack together together a test patch to stop it doing
that, and perhaps you could report if there is any change in behaviour.
> Should I create items for these in the bug tracker?
> Anybody observed anything similar?
I'm not sure about the tracker - you can do, but if so, please note the
branch and SHA1 as you did above. Let me take a look now to save you the
trouble of filing the bug.. I hate looking through Sourceforge anyway.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?= wrote: > Anybody observed anything similar? I use Peter C's "before pours" branch of pcb and see none of these artefacts and segfaults. My desktop environment is gnome with metacity as a window manager. All from debian/testing, i.e. squeeze. Maybe some weird problem with your graphics driver? ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Next problem, PCB looses rats
Do we use alt for anything else? Would alt-click interfere with window managers? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Next problem, PCB looses rats
DJ Delorie wrote: >> ack. The necessity to deactivate auto-DRC is a crutch. Does the internal >> representation prevent this to be fixed? > > Yup. It's based on touch/no-touch tests, not "which net" tests, since > we don't associate nets with copper. Then how about making the crutch easier to handle: "Press [alt] while drawing a track to temporarily disable auto-DRC" ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
All,
I have noticed two bugs with recent git versions of gl-enabled pcb
(6507083b0401e0).
1) Garbage is displayed outside of board area.
Contents are flashing annoyingly (black/background color) on every mouse
move event within the PCB drawing area. Contents of the drawing area
not occupied by the board depend on what was displayed in other windows,
ie after switching virtual desktops content from previous application
can be seen in the background.
Output of glxinfo and screenshot after rotating an empty board in 3d
space are attached.
2) pcb sometimes segfaults in glEnable() during startup.
I'm using tiling WM and in some cases pcb segfaults during startup.
I suspect this depends on the order of X events being sent to the
application. Stack trace is attached. If needed I can do more
debugging/build with debug libs, but I'm no X expert :)
Should I create items for these in the bug tracker?
Anybody observed anything similar?
Best regards,
--
Krzysztof Kościuszkiewicz
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci
(gdb) run
Starting program: /home/kokr/geda/bin/pcb
[Thread debugging using libthread_db enabled]
[New Thread 0xb68a2aa0 (LWP 15078)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb68a2aa0 (LWP 15078)]
0xb6dec616 in glEnable () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb6dec616 in glEnable () from /usr/lib/libGL.so.1
#1 0x081194f7 in ghid_show_crosshair (show=0) at
hid/gtk/gui-output-events.c:614
#2 0x0811a129 in ghid_port_window_leave_cb (widget=0x829d5e0, ev=0x83fc148,
out=0x81db6a0)
at hid/gtk/gui-output-events.c:2302
#3 0xb74ee374 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#4 0x0829d5e0 in ?? ()
#5 0x083fc148 in ?? ()
#6 0x081db6a0 in ?? ()
#7 0xb70765ba in ?? () from /usr/lib/libgobject-2.0.so.0
#8 0x0002 in ?? ()
#9 0x0008 in ?? ()
#10 0xb6cf73c0 in ?? () from /lib/i686/cmov/libc.so.6
#11 0xb70925a4 in g_type_check_instance_is_a () from
/usr/lib/libgobject-2.0.so.0
#12 0xb7077f62 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb708c3a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#14 0x08410430 in ?? ()
#15 0xbfd00c24 in ?? ()
#16 0x0002 in ?? ()
#17 0x0843d4f0 in ?? ()
#18 0xbfd00c10 in ?? ()
#19 0x0843d4f0 in ?? ()
#20 0xbfd00bc8 in ?? ()
#21 0xb707a272 in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#22 0xb708d5b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#23 0xb708dba6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#24 0xb760aafe in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x0829d5e0 in ?? ()
#26 0x002d in ?? ()
#27 0x in ?? ()
(gdb) fr 2
#2 0x0811a129 in ghid_port_window_leave_cb (widget=0x829d5e0, ev=0x83fc148,
out=0x81db6a0)
at hid/gtk/gui-output-events.c:2302
2302 ghid_show_crosshair (FALSE);
(gdb) p widget
$6 = (GtkWidget *) 0x829d5e0
(gdb) p *widget
$7 = {object = {parent_instance = {g_type_instance = {g_class = 0x83f31c8},
ref_count = 4,
qdata = 0x84129d0}, flags = 73664}, private_flags = 3584, state = 0 '\0',
saved_state = 0 '\0', name = 0x0, style = 0x8228458, requisition = {width =
0, height = 0},
allocation = {x = 0, y = 0, width = 547, height = 806}, window = 0x84110a8,
parent = 0x8232778}
(gdb) p ev
$8 = (GdkEventCrossing *) 0x83fc148
(gdb) p *ev
$9 = {type = GDK_LEAVE_NOTIFY, window = 0x84110a8, send_event = 0 '\0',
subwindow = 0x0,
time = 248194684, x = 388, y = 328, x_root = 541, y_root = 380, mode =
GDK_CROSSING_NORMAL,
detail = GDK_NOTIFY_ANCESTOR, focus = 0, state = 16}
(gdb) p out
$10 = (GHidPort *) 0x81db6a0
(gdb) p *out
$11 = {top_window = 0x8225850, drawing_area = 0x829d5e0, trackball = 0x8408000,
pixmap = 0x8403480,
mask = 0x0, drawable = 0x8403480, width = 547, height = 806, glconfig =
0x81fdc78,
trans_lines = 0, bg_color = {pixel = 15066597, red = 58853, green = 58853,
blue = 58853},
offlimits_color = {pixel = 13421772, red = 52428, green = 52428, blue =
52428}, grid_color = {
pixel = 0, red = 0, green = 0, blue = 0}, colormap = 0x8200818, X_cursor =
0x8426368,
X_cursor_shape = GDK_LEFT_PTR, has_entered = 1, panning = 0, zoom =
1096.892138939671,
view_x0 = 0, view_y0 = 0, view_width = 60, view_height = 50, view_x =
116400,
view_y = 98400, x_crosshair = 116000, y_crosshair = 98000}
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX
Re: gEDA-user: Next problem, PCB looses rats
> ack. The necessity to deactivate auto-DRC is a crutch. Does the internal > representation prevent this to be fixed? Yup. It's based on touch/no-touch tests, not "which net" tests, since we don't associate nets with copper. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: git HEAD PCB now supports user-defined holes in polygons
Peter Clifton wrote: > A subsequent commit also introduced a GUI tool for creating holes in > polygons. Standard editing tools such as insert / move / remove point > work on the holes too. Great! Does this apply to solder stop, too? --<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Next problem, PCB looses rats
Armin Faltl wrote: > There is one known shortcoming with PCB (iirc): if you create a "copper > island" somewhere, that is a copper area not connected to anything with > a know net, this gets a hidden ID and is not treated as undefined. ack. The necessity to deactivate auto-DRC is a crutch. Does the internal representation prevent this to be fixed? ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Next problem, PCB looses rats
I found where I have moved a component slightly a caused a short between ground an power. I got all that fixed. But every time I start to run the power buss, I reach a point where pins are highlighted green, but the rat lines disappear, and the DRC makes it impossible to run a trace to the pin. I have to keep saving the layout, exiting the program, and starting over. Even reloading the net list and displaying the rat lines does not help. This is slowing things down quit a bit. But I don't think I can build a 4 layer board at home, and with only two layers, there is no ground an power planes, so I want the power and ground lines thick and well laid out, so I don't want to rey autorouting just yet. What I am doing wrong this time There is one known shortcoming with PCB (iirc): if you create a "copper island" somewhere, that is a copper area not connected to anything with a know net, this gets a hidden ID and is not treated as undefined. So if you layout a strip of copper you intend to become part of e.g. ground later, once you want to connect it to a known ground you have to turn off auto-DRC for this one connection. As long as that area is not shorted to anything else the next rats-optimization should show no trouble. Don't forget to turn on auto-DRC again after the deliberate "forced shorting". HTH, Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Polygon combiner plugin
On Mon, 2010-06-07 at 14:37 +0200, Armin Faltl wrote: > The answer was enlightening, though I'd have to do a lot more thinking about > why it doesn't matter, if some polygons are intersecting. Not necessarily that the result doesn't matter, rather - that the "correct" result is not so easily defined in the first place. From what I could tell, pstoedit emits mostly non-intersecting contours. > If a polygone is complex, i.e. has holes, the cast ray will pass an odd > number > of edges, if the start point is inside the polygon. Numerically > difficult is the > case, if the ray scratches a corner. I assume, your ray is an axe-direction > and you sort the edges before checking hits or something. So if an > interval-test > shows, that it's a corner and you are lucky to have a minimal delta from > previous edge-sorting, you may slightly offset the start point along an edge > and rerun the test (the sorting delta is a bound for the offset?). I'm not sure.. I didn't write that code, it is part of PCB's polygon1.c which Harry Eaton wrote (based upon the excellent work and code of some researchers who studied polygon algorithms). > Hm - many polygons are axe-aligned, so a ray in a rather random direction > is much less likely to produce corner cases. Otoh, when using an axe-aligned > ray, the intersection test for an edge degenerates to an > interval-inclusion and > a true intersection only if this hits, so rotating the input beforehand > (say 1 rad) may be desirable ;-) The direction it still pretty arbitrary though, so in general it doesn't help. I "think" PCB's code is known to work in the degenerate cases for this particular test. (There are others it can fail on though, due to numerical precision). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Polygon combiner plugin
The answer was enlightening, though I'd have to do a lot more thinking about why it doesn't matter, if some polygons are intersecting. If a polygone is complex, i.e. has holes, the cast ray will pass an odd number of edges, if the start point is inside the polygon. Numerically difficult is the case, if the ray scratches a corner. I assume, your ray is an axe-direction and you sort the edges before checking hits or something. So if an interval-test shows, that it's a corner and you are lucky to have a minimal delta from previous edge-sorting, you may slightly offset the start point along an edge and rerun the test (the sorting delta is a bound for the offset?). Hm - many polygons are axe-aligned, so a ray in a rather random direction is much less likely to produce corner cases. Otoh, when using an axe-aligned ray, the intersection test for an edge degenerates to an interval-inclusion and a true intersection only if this hits, so rotating the input beforehand (say 1 rad) may be desirable ;-) Thanks, Armin Peter Clifton wrote: On Mon, 2010-06-07 at 11:21 +0200, Armin Faltl wrote: Peter Clifton wrote: The plugin now works to construct a tree ordered by "containership" - and processes the relevant contours in an appropriate order so outer contours are processed before inner ones. How do you determine containership? Now you're asking me a HARD question ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Polygon combiner plugin
On Mon, 2010-06-07 at 12:02 +0100, Peter Clifton wrote: > The inside / outside testing in poly_InsideContour() works by casting a > ray in a particular direction from the point being outwards, and __ being tested > counting intersections between that ray and polygon edges. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Polygon combiner plugin
On Mon, 2010-06-07 at 11:21 +0200, Armin Faltl wrote:
> Peter Clifton wrote:
> > The plugin now works to construct a tree ordered by "containership" -
> > and processes the relevant contours in an appropriate order so outer
> > contours are processed before inner ones.
> >
> How do you determine containership?
Now you're asking me a HARD question ;)
polygoncombine.c defines a helper function, PolygonContainsPolygon()
which is supposed to compute the "correct" result. As a cheat (which
seemed to work), I make this simply:
static bool
PolygonContainsPolygon (POLYAREA *outer, POLYAREA *inner)
{
return poly_ContourInContour (outer->contours, inner->contours);
}
(Which is a function in polygon1.c).
Note that I'm _assuming_ the input polygons to "combinepolygon" only
have a single contour, since poly_ContourInContour() only operates on
the FIRST contour in the linked list passed. (I think). I'm not entirely
sure how I'd go about writing this test if I were working with complex
polygons.
poly_ContourInContour, however, makes a big assumption:
That the caller _knows_ the contours it is asking about don't INTERSECT.
If they _do_ intersect, the result from the function is undetermined.
(e.g. Random, based upon implementation details.)
In our case, I can guess that the contours won't intersect (for "normal"
input data), but I don't KNOW they don't intersect. (Debug output
suggests that some "might" in the example I posted).
Fortunately, it doesn't _really_ matter if we get a bad report for
containership between two intersecting contours, so I've not bothered
proving the contours don't intersect.
poly_ContourInContour() works like this:
1. Check bounding boxes as a quick way of throwing out a false answer
2. Pick the first point on the contour we're testing to be "inside" the
"outer" contour, and run a test to prove it is not outside that. This is
done with a call to poly_InsideContour().
3. Compute a point which is inside the "inside" contour, and away from
its edges. Test _that_ point, to prove it is not outside the "outside"
contour.
(This avoids a false result if the two contours are separate, but the
point tested in step 2 shares a point with the "outer" contour).
The inside / outside testing in poly_InsideContour() works by casting a
ray in a particular direction from the point being outwards, and
counting intersections between that ray and polygon edges.
I hope that was enlightening.. I hope this was the kind of explanation
you were after. Let me know if you wanted any other details, and I'll
try to fill them in.
Best regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Polygon combiner plugin
Peter Clifton wrote: The plugin now works to construct a tree ordered by "containership" - and processes the relevant contours in an appropriate order so outer contours are processed before inner ones. How do you determine containership? Tanks in advance ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
