X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 9 Sep 2015 12:53:23 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Erich Heinzle (a1039181 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [OT] looking for a PADS layout person (GERBER -->
 PCB)
In-Reply-To: <CAHUm0tOnDpRa9CnxRxgkZC2qf_a1jjXKmxA+w-r_Q5G-F=g5rQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1509091242580.6924@igor2priv>
References: <1509040703 DOT AA09605 AT ivan DOT Harhan DOT ORG> <CA+KzSgJ-1K_Kt5ycwMC8j0qV8UsjXWGQqMfKfzhuY4qy=GK6ag AT mail DOT gmail DOT com> <CAM2RGhSucTr7=EOiwwRx62Dc=tx3xOumvHGg4YdZ5KE2jyHWqQ AT mail DOT gmail DOT com> <20150904192626 DOT e7e840eed7bf8e2e3e418f79 AT gmail DOT com>
 <CAHUm0tOYOFgAbCbnKcw3Og5ORGCvML0GEefeORhE08J7j-51iw AT mail DOT gmail DOT com> <20150909092512 DOT b2354e50a1028463c8f819bd AT gmail DOT com> <CAHUm0tNjdWUGFZo2J3f8vuN_L_CNQ02nvUz9zzMcL7S4iZW4vg AT mail DOT gmail DOT com> <20150909113706 DOT 30b44e944c08b590f146d9f2 AT gmail DOT com>
 <CAHUm0tOnDpRa9CnxRxgkZC2qf_a1jjXKmxA+w-r_Q5G-F=g5rQ AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 Wed, 9 Sep 2015, Erich Heinzle (a1039181 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

>If apertures were properly implemented for non round pins/pads, it would
>
>a) make it more Ucamco standard compliant
>b) perhaps simplify the implementation of additional features in future,
>i.e. tear drop pads, obround pads.

I do have native support for assymetrical shaped pins (sort of teardrops) 
in pcb-rnd.

While flashing is probably good for gerber, it doesn't make things easier 
with the current infra: rectangular and octagonal pins are 
polygons. If they are just polygons, the code can calculate them and 
place them without having to worry about other pins. The user presses 's' 
and they grow, or presses 'q' and change shape - locally. It's relatively 
easy to implement with the generic polygon idea.

If they have to be flashed, and you decide to make this in pcb core, you 
need to make a catalogue of all the shapes you used. When 
the user presses 's', you need to check whether this was the last 
reference of the given sized/shaped pin so you can remove unused 
catalogue items and then check whether the new size/shape already has an 
item and increase the reference counter or create the item. Changes are 
not local anymore, you need to start worrying about saving the flash 
catalogue in the pcb file or generating it on load, etc.

If you don't do it in the core but in the gerber exporter (which is imo 
much simpler), you need to build the same catalogue, but only once, when 
you start, and you don't need to delete from it ever, just delete the 
whole thing at the end of the export. So no reference counting, just an 
index of shapes alerady seen. Probably something like this is already 
happening for line widths and/or hole sizes.


Regards,

Igor2