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 <davecurtis AT sonic DOT net>
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>
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

- Raw text -