kicad-developers team mailing list archive
Mailing list archive
Re: EDA in a better (open and free) world :-)]
Dick Hollenbeck <dick@...>
Wed, 26 Mar 2008 09:01:57 -0500
Thunderbird 184.108.40.206 (X11/20080227)
OK then. We should probably do the SPECCTRA DSN import next. I think
this will highlight the differences in document models, and make clear
where additional work is required to get to a point where our document
model more closely matches the SPECCTRA grammar. The *.dsn import is
moderately more complex than the completed session file (*.ses)
importer, adding the components and their graphic borders to the tracks
and vias which are already handled by the session file import function.
All you said is true.
Changes it pcbnew involve changes in .brd format.
.brd format is 15 years old, and was a compromise between a clear and
readable format (opposite to a binary format)
and the time to read a file (for a large boards) with PCs existing 15
It can be changed now.
(We can to stay with the current format forever only if forever does not
take a long time to finish)
Which is mandatory is only the ability for a recent pcbnew version to
read all the old board designs.
I have no preference for XML syntax or SPECCTRA grammar.
But i know what are some features for a new format:
A) It would be largely self documenting. : mandatory.
B) It would be easily parsed with standard software tools. : Sure...
C) It would have the capability to represent all the constructs in a PCB
Not all constructs would be present in each file, but the capacity
to represent them if needed is desirable.
I can add:
Format must be easily human readable (Edif is not easily readable...)
Data must be coded without any reference to its internal representation
Obviously, sizes and positions can be coded in inches or mm but not in
diam="12.5mm" or diam="0.5inch"
or something like
angle = "34.0" and not angle = 340 like now
This is very important in others items like layers, flags, options:
layer is bad, but
layer[copper] or layer.copper is better.
or something like:
layer = copper
before using layer.
This is true for all items like pads vias, tracks with are on one or
And of course mainly true to code flags and options (like pad shapes,
locked footprints, texts justification ...)
I also believe pcbnew internal units will be changed in a next future
from 1/10000 inch to a smaller unit (1/100000 inch or 1/10000 mm)
to handle properly small pad and track sizes in inches and mm because
modern components are smaller and smaller and use a small metric grid.
This also is a reason to change the .brd file format
I am starting to lean away from XML and towards the parentheses based
A) It is more concise, meaning smaller files.
B) Slightly easier to read as a human.
C) Faster to parse.
D) Our parser can indicate the precise location of an error nicely, and
with information that we control.
E) A SAX XML parser is not as clean as our recursive descent model,
which inherently tracks state better. And the alternative XML method,
an XML-DOM tree, leaves us having to navigate in memory XML-DOM nodes
rather than nodes designed according to our own needs.
I wonder if the benefits of XML could be addressed instead by a round
trip converter, one which could convert our new format to XML and back.
The elements in the XML format would exactly match the elements in the
parenthesis based file, so any grammar documents we have would apply the
same way to both.
Then in the XML world, anybody that likes XML could do their magic and
then simply run the return trip part of the XML round-tripper on the
XML result as a last step. This XML round-tripper utility could be
written later as a Python based Pcbnew macro, or in C++ as a standalone
command line utility. Or maybe XML never becomes necessary because
everything can be done with the Python on PCBNEW-DOM architecture.
What file extension should we use for the new format?