kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> jean-pierre.charras@... wrote:
>>> Jean-Pierre, do you want to do a board like this? Do you want me to do
>>> one? Or should we both do one and combine the concepts later?
>>>
>>> Dick
>>>
>>> 
>> I'll start this work asap.
>> But i am thinking 2 brains are better than one, and combine the concepts 
>> later is a good idea.
>> So feel free to also create such a board.
>> 
> 
> Attached are some ideas that I put together about the new format.
> 
> I will be working on the layer UI today, since I will be away from my 
> desk for a few days next week.
> 
> If I were able to get to an actual DSN board text file prototype, it 
> will be more than a week down the road. 
> 
> In the mean time, I suggest looking closely at the specctra DSN output 
> files, and looking up the
> descriptors as you get curious in the spec. The specctra descriptors 
> are all very well thought out.
> 
> And look over the attached document.

Dick,

I just finish looking over your latest richio/dsn commit. Nice! I
forgot to ask you last night if you were going to move this into the
common library. Obviously, you already had thought of that.

Have you given any thought to creating a base LEXER and FORMATTER for
objects that should be common to all of the Kicad file formats. I'm
thinking specifically of the component library and schematic file
formats. To me it makes sense to have tokens like headers, versions,
comments, and even low level drawable objects like lines, arcs,
polygons, etc. have a common format among files. This way you would
only have to implement the LEXER and FORMATTER for objects specific to a
given file type. It would potentially prevent things like arcs being
formatted one way in board files and a different way in schematic files
and yet another way in component library files. It would also cut down
on code duplication and make it easier to read the different Kicad file
formats. I could even see using it for the Kicad project file to remove
the dependency of wxWidgets' wxFileConfig to generate and parse the
project file.

I like the idea of defining the engineering units in the file. Have you
considered making the engineering units an integer divisor. Internally
this is how coordinates are represented already and you have the
advantage of making all of the coordinates in the file in integer
format. This should make the lexer easier to implement and the files no
less difficult to read. Even for E size drawings the maximum
coordinates with units of 10000 would be 340000 x 440000. If integer
overflows in wxWidgets are a concern, use wxMulDivInt32() defined in
<wx/math.h>. Obviously the wxWidgets developers have already run into
this problem. Unfortunately, this handy function isn't documented in
the wxWidgets documentation.

Wayne

> 
> Thanks,
> 
> Dick
> 
> 
> 
>