X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Wed, 9 Jul 2014 13:57:13 -0400
Message-Id: <201407091757.s69HvCq0022117@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <hy3k3tfjgbnf6pe3r6efesvv.1404910483313@email.android.com>
	(message from Peter Clifton on Wed, 09 Jul 2014 13:58:44 +0100)
Subject: Re: [geda-user] pour clearing around pads
References: <hy3k3tfjgbnf6pe3r6efesvv DOT 1404910483313 AT email DOT android DOT com>
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


> Alternatively, take the view that the variations are infact distinct
> footprints.

In my blue-sky on the subject, I mentioned a database of selection
criteria, and the criteria could be part-specific or project-wide.  So
if you had a field for "hand-solderable" that selected between normal
footprints for reflow, or extended pads for home soldering, you could
use that field to select alternate footprints.

But that assumes you have a fairly complex database mapping groups of
symbols to groups of components which select groups of footprints.
*That* I've used before, way back when, but it was a very small
database.

> OR.. That the variations could (for some cases) be applied in a
> mapping / post processing step during CAM export.

There's no reason why footprints can't be dynamically generated based
on parameters.  We started with the m4 library and migrated to a fixed
library to better support Windows and the parts library dialog, but if
we can come up with a better way of doing it...