joe tarantino wrote: > - Expanding the grammar to support inner layer pad <> outer layer pad > would be great. (Would one geometry definition apply to all inner layers?) > - Also consider whatever would allow pins (and vias) with no connection > to some layers (maybe supporting blind and buried vias in the process?)
I'll let people more expert on PCB fabrication comment on those. > - Taking this too the limit, consider a shift to a more heirarchical > approach which would allow pad definitions to be "included" in a > footprint by reference rather than direct inclusion. While I can see what you are trying to accomplish, I think having to have a pad library in addition to a footprint library is a nightmare in waiting. It certainly makes footprint sharing more difficult. IMHO footprints need to be self-contained. Seems to me that the most balanced solution is to allow "pad stack" (as DJ calls them) definitions within a footprint, and instantiate those in the self-same footprint, which allows for hierarchical definition but still keep the footprint self contained. What I would probably end up doing is simulating the pad library with a script that looked for ##padname=blivit ... ##endpad comments and did a swapparroo so that a all instances of a "library pad" could be updated easily. Kludgey, but I think I'd rather do that than institutionalize a more fragmented footprint definition. -dave _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user