X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Message-ID: <1404869573.3730.30.camel@pcjc2lap> Subject: Re: [geda-user] pour clearing around pads From: Peter Clifton To: geda-user AT delorie DOT com Date: Wed, 09 Jul 2014 02:32:53 +0100 In-Reply-To: <1404719914.750.49@zotlet.(none)> References: <1404719914 DOT 750 DOT 49 AT zotlet.(none)> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 2014-07-07 at 19:58 +1200, Lilith Bryant wrote: > > > > Not exactly, and it may not work when multiple different objects combine to > > create a thin feature. > > Can you describe such a case. I can't see how this could be? For mask cutouts, what I meant was that it would only work for global application to the entire board at one time. I don't think it would work nicely with our usual incremental approach to polygon management. For application to general polygons - there are some fundamental problems. One, in particular, is if the outer contour is explicitly defined such that it violates a min-width rule in a necked-down region. If you shrink this polygon (by subtracting a line for each edge of its contour), it will breaks into two pieces either side of the necked region. PCB's connectivity checking code would not cope with that, the only way it would cope with the current code-base if you deliberately threw away one of the pieces. Bloating a convex part of the polygon (after shrinking) will also introduce rounded corners, not necessarily an issue - but also not necessarily what people might want, or expect. Certainly it would be a break from what we currently expect. The method could be used to remove sharp corners from spikes on polygons, but something "feels" wrong with insisting on radiusing say, a 90 degree corner of a power plane, just because it happened to go through this code-path. This is one of the reasons I never did anything with that idea when we looked at it before. A long ago, I had a git branch which addressed this "one piece kept" issue, allowing one "pour" once disected by tracking, to contribute to connectivity of any number of different nets. The branch had code to allow keeping every piece of a poured polygon, and optionally - introduced island removal logic to only keep those pieces which were electrically connected to something. I'll perhaps revive the branch one day. For reference, I used the word "pour" in the branch to indicate the "correct", non-piece-throwing-away behaviour, in contrast to PCB's current "polygons". -- Peter Clifton Clifton Electronics