On 7/30/2016 9:22 PM, Chris Pavlina wrote: > Hi, > > I was reading through the new sch/lib format documents posted back in > February: https://lists.launchpad.net/kicad-developers/msg23302.html > > Since work is underway to facilitate adding this now, I figured it was a > decent time to bring up a few concerns and suggestions I have. Bear in > mind I'm working off a pretty old version of the document here - if it's > been updated and some of this has changed, feel free to point me to a > more recent version; I couldn't find one.
I don't believe I've changed it since the last time I published it on the mailing list. > > - I think we should work to reduce redundancies in the format. They just > confuse things and introduce parsing complexities (what happens when > A implies B, both are written to the file, and they don't agree with > each other?). Examples: > > - Why both 'polyline' and 'line'? Surely eeschema isn't going to get > tired of writing 'poly' and decide to start abbreviating it? Can't > we remove one? Agreed. 'lines' could be one or more lines that may or may not form a polygon. > > - Arcs have redundant information, we only need either (radius, start > angle, end angle, center), or (start point, end point, center). I > suggest sticking to the former and dropping the start/end points. We currently save all of this information in the for an arc. I'm not sure why. I'm fine with this proposal. One advantage to using the end points rather than the angles is round errors to ensure completely enclosed drawings but I don't know if that is an issue or not. > > - Can we consider adding power ports as a type of label rather than > component, so we don't have to maintain libraries of every possible > rail name anymore? I'd happily contribute to the implementation - I > have an old feature branch where I did exactly that, it worked really > well :) I thought that was in there already. Maybe I missed it. There will be a symbol type token. We have to support normal, power, virtual (show up in BOM but not netlist, could have a better name not-in-netlist?), and not-in-bom? (for net ties at a minimum, maybe net-tie would be a better name but it could be used for other not in BOM objects that we have yet thought of). > > - There's a vague comment that fonts aren't supported yet but may be in > the future. We should specify *now* how upcoming pre-font versions of > kicad should handle future files that have been saved using fonts, and > make sure they actually can. Yep, that code will need to be tested. The EDA_FONT object already can format itself to s-expr it just hasn't been tested yet. Now that freetype is a dependency, I'm hoping we can do some more interesting things with fonts in PCBs. In schematics, custom fonts are less problematic other than the age old issue of font availability. > > - It looks like the new format may allow an arbitrary number of > "alternates", not just the one "De Morgan equivalent" that we allow > now. Is this true? I'd love that. Yes, don't see any reason that there is only a single alternate body style. It will require changes to the component editor. > > - Can we ditch 'keywords'? It's not useful anymore, the new component > search doesn't use it and does a fine job of sifting through tokens in > descriptions. We may not want to throw them out. They could be useful for third party tools. I'm thinking tags here which is probably a better token than keywords. I'm not dismissing this idea but I have a feeling that they could prove useful. > > - "Are there any other per net hints besides net classes?" - we should > allow them! They're just hints - allow the format to have arbitrary > ones that will just be ignored by a pcbnew that doesn't understand > them. They are called properties in the board file format and they can be define in any object. I plan on using that same paradigm in the new schematic file format. Properties are for third party tools which kicad knows nor cares anything about. AFAIK there is no limit to their use or definition and they are simple key/value pairs. > > - Can we add controllable line _color_ as well as style? And also for > wires? (people making wiring diagrams will like that.) I don't see any reason not to add an optional color expression to all objects where it makes sense. Of course the code will need to be added to the objects (EDA_ITEM?) themselves and fall back to the defaults when no color is defined. > > - BUG: bus_entry is missing an angle specifier - it's possible to > rotate/flip them. Good catch. > A few more that didn't make it into the latest spec but I'm planning on implementing: * Embedded components with an option to link. Initially linking will only support internal linking but eventually it will grow to support other external linking such as file, ftp, http, etc. The link format will be a uri. For internally linked components the format will look something like sch:\\SCH_NAME\COMPONENT_NAME. * I am considering forgoing the unitless idea at least in the first pass. As much as I like the idea, the task of implementing it would be monumental and I just don't want to change that much of the Eeschema internals in one shot. I'm already having to make way more changes than I'm comfortable with to support the new I/O plugin. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
