[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: constructive geometry (was Re: final modification)



Hi all,

On Thu, 2008-11-06 at 15:22 -0500, Ethan Swint wrote:
> Bert Timmerman wrote:
> > Modifying the existing polygon would probably become too cumbersome if
> > new vertices need be added and holes ("negative" copper) in polygons to
> > be defined in ways currently not feasible within the current pcb file
> > format.
> >   
> Ah - back to the file format. ;)  Would it be difficult to add in a 
> final "positive/negative" argument to the polygon definition, which, if 
> absent, defaults to "positive"?  (I think I already know the answer, but 
> yet I ask...)

Let me first say that I do not consider myself a pcb-developer :)
I do not push code into the pcb CVS repository myself, I merely try to
contribute with patches.
And BTW I'd rather have somebody else have a look on my code before the
forthcoming mayhem is only to blame on me :)

And yes the pcb file format.

When and if the pcb file format needs to be improved, it needs to be
done :)

Prior to that one can think up proper definitions of multi layered pad
stacks, keepout and all sorts of other layers with special meanings etc.
and polygons for "negative" copper pours and buried vias and hatching
(thieving) and discuss those on the mailing list.

If you think it needs to be done, cook up a patch (or series of) and
contribute to the SF trackers.

After that you can advocate the pros and cons of new vs. existing on the
geda-dev list with __real__ arguments.

Yeah, I know, this will keep you busy for a couple of hours.

BTW the pcb file format change subject rears it's head every now and
then (almost twice a year) on the geda-dev list (for some reason or
another when the leaves on trees start to fall/grow).

Just my EUR 0.02

Kind regards,

Bert Timmerman.

> > BTW: would the "OR" operation result in an overlapping polygons, would
> > the "AND" operation result in the intersection of two polygons, and
> > would the "XOR" operation result in "negative" copper (a.k.a. a hole)
> > where two polygons were overlapping and leave "positive" copper where
> > only one of the two former polygons touched the laminate ?
> >   
> The AND and OR of two overlapping polygons would both end up with a 
> single, final polygon, e.g. square AND circle => a quarter circle; 
> square OR circle => circle with a square protruding from it.  XOR could 
> result in a "negative" copper space, if one geometry is completely 
> contained within the other; square XOR circle => square w/ circular hole 
> (a la square pin for a component).  Otherwise, the geometry would be 
> broken into two new geometries, touching at the former intersection 
> points, square XOR circle => 3/4 circle and all that's left of the 
> square is an "arrowhead" shape.
> 
> I wonder how the code presently handles the "negative" copper that 
> results from a pad/track/via that has the "clears polygon" flag set?
> 
> -Ethan
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user