X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <53BE0E7C.7050809@sonic.net> Date: Wed, 09 Jul 2014 20:54:36 -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: Layers and footprints (was: Re: [geda-user] pour clearing around pads) References: <201407091750 DOT s69HofTL021912 AT envy DOT delorie DOT com> In-Reply-To: <201407091750.s69HofTL021912@envy.delorie.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;ZtHy6OUH5BGPqU2zUc16mQ== M;hkQo6eUH5BGPqU2zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Reply-To: geda-user AT delorie DOT com On 07/09/2014 10:50 AM, DJ Delorie wrote: >> I think any layer objects embeded in footprints (might as well include silk and copper in the same way going forward), ought to reference predefined symbolic layer name or ID. >> >> "TOP-SILK" "TOP-MASK" "TOP-COPPER" "INNER-COPPER" "INNER-ANTI-COPPER"* "BOTTOM-COPPER" etc... >> >> *(inner anticopper might need some thought, possibly not one for today!). > Yeah, IMHO symbolic layers is a must. > > I also think we need a way of "stacking" or "nesting" drawing layers > within a physical layer to do fill/cut/draw operations. For example: > > * "Fill" - positive, first rendered, used for power plane polygons > * "Cut" - used for keep-outs, and cutting planes into sub-planes with traces > * "Trace" - used to draw traces over polygons (clear polygons but ignore cuts) > > Each layer needs a positive/negative flag, so you could (for example) > draw negative text over a filled rectangle. > > But given that footprints might have their own fill/cut/trace layers, > which may be drawn on top of the board-layer cuts, we need to be > flexible in making these stacks... > > * board-level fill > * board-level cut > * footprint-level fill > * footprint-level cut > * traces > > but if you want to support "sub-layouts" it gets even more complex. > > Perhaps a heirarchical design? > > * board-level fill > * board-level cut > * sub-layouts and footprints -> > * . . . > * . . . > * . . . > * board-level traces > > And all that is just *per layer* It strikes me that this is an excellent layer model for talking about footprint models, even though pcb doesn't support arbitrary symbolic layers. If we define a model consisting of symbolic logic layers, each containing sublayers, and define rendering rules, then we can map what pcb *currently* does onto that same model. So while ultimately it would be great if users could create arbitrary layer stacks with arbitrary names, and define their rendering order, right now today pcb *has* a set of logical layers, with defined names, and a defined rendering order. That means one could go ahead and define a footprint model around some future flexible layer model. The footprint file format can target the flexible layer model, its just that if you code a footprint today there is exactly one layer model available to you, with pre-defined layer names, so your footprint needs to live within those constraints. As pcb moves forward, more of the semantics of the footprint model become available as layer constraints are relaxed.