kicad-developers team mailing list archive

[Vesa Solonen <vesa.solonen@xxxxxxxx>]

05/04/14 13:35, Heiko Rosemann kirjoitti:

> Let me stress that I'm not writing this as a "please someone
> implement this" eMail, it's just a few thoughts about what I would
> consider most helpful.

To get a bit forward I'm asking interested team members to join in
designing relevant file format _specification_ description of
components. No consideration should be given to implementation
details, but what information must be there and how interdependencies
must be handled. The file format etc. may never get implemented, but
at least there would be documentation to start from if someone would
miraculously see value in implementing it.

As a means how to do that I propose adding a folder to documentation
VCS. Or if it's easier and less risky, ask Dick to open one more
branch for us – maybe even on Github. The supporting discussion on
this list under a proper topic subject, but all specifications written
in relevant (plain text?)files and change logs in commit logs.


The rough idea what all of this should contain:


1) Device description data

Interdependencies between documentation, logical schematic symbols and
physical layout footprints and 3D-models. Gate/pin swap data. Back and
forward annotation support. Dynamic building of
parts(devices/components) from any symbol and a footprint(or pcb
fragment). 3D must be here as many 3D models may be linked to a same
2D-footprint. The possibility of bundling _everything_ in one DDD-file
in case of special parts that consists fully non standard and non
reusable symbol/footprint section. My topmost idea for the DDD bundle
option is some standard archive format ~zip/tar. Individual bundles
like current footprints in a library folder.


2) Symbols

The schematic symbols that eventually could reduce to a subset of SVG.
No pin text or anything but symbol and pin locations must be hard
coded here. Eventually someone is willing to migrate away from current
embedded vector font in schematics anyway.


3) Footprints

Do we need any additional information/functionality or not. IIRC it
was already said that any PCB fragment should/could eventually make a
footprint. I see it's not exactly easy.


4) Something I forgot

Please see subject and search some more in archives.


-Vesa