On Sat, Sep 04, 2010 at 07:50:51PM -0400, Ethan Swint wrote: > In parallel to how we want to implement the PCB file format, why > don't we have a separate thread on *what* we want to implement? > I'll propose the following as a starting point: > > 1) Better angle support: include rotation (in degrees, > rotation/translation matrix, whatever) as a location argument > instead of altering the pad/pin/silk/refdes/whatever location data > separately
Definitely. We probably also want transformation information, in case the use needs to shunt the footprint over a few tenths-of-mils to make the component match the PCB grid. > 2) Footprint re-use: reduce file size by having components refer to > a 'base' component with XYRS information, make component tweaking > easier. Say you wanted to change all your 0603 resistors - it's > easier to change the fundamental component, rather than the present > case of to modifying individual components in all of their > rotations. Agreed - we should only import footprints once (and the format should support referencing external files, even if pcb itself doesn't give a GUI way to do this), and tag components. This fits in well with point #1. > 3) Connectivity information: include the connection information > between line segments, similar to (but not necessarily exactly!) SVG > format, where multiple points and arcs can be included in one line. I'm not sure what you're getting at here. I think the rule of least surprise dictates that line segments be line segments, since that is how they are manipulated. However, it would be nice if pcb supported shift-dragging to maintain connections while moving segments; also, if you could double-click segments to select the entire trace. But that's another discussion. > 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing > the DRC at every instance. DRC rules could be arbitrarily complex > or simple, e.g. elements in DRC class '250V' must have a 0.050" > clearance from class '5V', but can have 0.010" clearance within > '250V', or something along the lines of the 'skinny, normal, fat, > power' we have in place now. Yes. Though naturally there shouldn't be any limits on the number of DRC classes, rules inside classes, etc. > 5) Ability to lock any portion of the location coordinate, either in > absolute or relative to another entity (line segment locked to > pin/pad, components locked to the same Y coordinate, etc) - rather > than just specifying an absolute coordinate. > More generally, we should support creating "groups" of components that can be transformed and manipulated as a collection. However, I'm not sure how much functionality this would give on top of the functional-block proposal. > We might not be able to use this flexibility until PCB's internals > are modified, but the ability will be there, waiting to be tapped. > The dream is that we never have to make a breaking change again :). Andrew _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
