X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <53CDEB64.2010408@sonic.net> Date: Mon, 21 Jul 2014 21:41:08 -0700 From: Dave Curtis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] Octagon flag on Pad[] References: <53C69EB6 DOT 6030003 AT sonic DOT net> <53C6B815 DOT 10108 AT sonic DOT net> <1405875201 DOT 394 DOT 7 DOT camel AT pcjc2lap> In-Reply-To: <1405875201.394.7.camel@pcjc2lap> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;DnsZZloR5BG37E2zUc16mQ== M;ejeqZloR5BG37E2zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Reply-To: geda-user AT delorie DOT com On 07/20/2014 09:53 AM, Peter Clifton wrote: > On Wed, 2014-07-16 at 10:36 -0700, Dave Curtis wrote: >> On 07/16/2014 02:56 AM, Peter C.J. Clifton wrote: >>> On 2014-07-15 05:41, Dave Curtis wrote: >>>> On 07/14/2014 09:09 PM, DJ Delorie wrote: >>>>>> "octagon" flag appears to do nothing on Pad[] directives. Is this >>>>>> correct? >>>>> >>>>> Correct. >>>>> >>>> Is that by plan? A friend and I are looking at "challenging footprint >>>> specs" (we're easily entertained..) and I've seen a couple where an >>>> interpolated octagon could be helpful. >>> >>> Thats a poly-curve. >>> >>> (As are ROUND pads, obround pads, square, .... (you get the idea). >> >> Well, but octagons are a RS-274X pad macro primitive, both flashed and >> stroked, so they are fair game for footprint pad construction. > > I'd prefer to model things more generically in future, not by using > classes of template objects. > > If we can always model a pad as a polygon / polycurve, it cuts out the > multiple choice code-paths where we must select ("Is it square-ended, is > it round-ended, (is it an octagon)"...) While I'm all for mathematical elegance and generalization, it seems like that kind of decomposition works against us here. A drawing model which targets the available primitives is going to require a lot less code trying to re-construct what the user intended. Data sheet footprints are going to assume RS-274X macros. Drawing them in some other model and expecting the tool to reconstitute the macros from soup is just making life hard for ourselves. > >> I guess I don't understand the logic of not allowing the octagon flag on >> Pad[]'s, since they are allowed on Pin[]'s. It seems to me that all the >> logic should be there to draw them -- wouldn't they be handled the same >> as a square aperture, even when the pad is parallel to the X/Y axes? > > Square pads are already broken for rotation, no need to add octagons to > the list of broken geometric primitives as well! Now that I understand that square pads are not being drawn using a square aperture, it makes sense. I think you made the point of my paragraph above for me. -dave