kicad-developers team mailing list archive

["viking632" <oyvind.aabling@...>]

> Dick Hollenbeck a écrit :
> >
> >
> > Øyvind,
> >
> > On this topic, I think we need major input from Jean-Pierre.
> Well , I believe we *must* make the difference between file formats an the internal representation in pcbnew or eeschema.
> the current file format is an image of the internal representation of data in Eeschema and Pcbnew.
> This is due to the history of Kicad.
> This was a reasonable idea, and the limited speed of computers did not allow a more sophisticated format.
>
> But now, this speed is not a problem.
> So we consider the file formats that can be more complex) and the file format are 2 separate problems.
> - if the internal units are changed, the file formats must be changed.

Not necessarily, just multiply all coords in the existing file formats by 25400 or 2540 to get to the internal 100nm unit, and divide coords when saving.
This will be all that is needed with regard to coords for the current fileformats if the IU is ever changed.
Of course, writing an old format file will potentially loose some precision, but that is unavoidable.

> - but if the file formats must is changed, this new format must be designed to store data regardless of the internal representation of this data.

Yes, always a good idea, and I did suggest to add the unit used into the fileformat, making at least that part of it independant :-)

> Let me give an example:
> For now, a footprint data has a lot of coordinates (pads coordinates for instance) stored as physical coordinates.
> So these values depend on (for different instances of the same footprint)its orientation, board side ...
> The pads layers representation in .brd files also depends on the internalidentifications of layers in Pcbnew.
> A good file format must avoid this problem.
> (Obviously, saving a file in binary is the most stupid thing we can do. But a lot of software do that.
> But i believe this is mainly to trap users of software)

Yes, avoid binary files like the plague :-)

> So, when the internal units of Pcbnew will be changed, the file format will be redesigned.
> (a lot of others things could be changed, like the layers handling, because in few years, 16 copper layers could be not enough)
> But the new file format must be carefully redesigned to be independent ofinternal Pcbnew units,
> and also independent of details of internal representation.
>
> This is a *lot* of work, and means also a *lot* of time to achieve this.
>
> And, we also think about using an existing file format like a specctra .dsn format.

If there are file formats in existance that would do a better job, I agree:Yes, use those (unless they're binary, let's avoid those, please) ...

> For now, remember the internal unit is 1/10000 inch or 2,5 um, and this is currently enough for *all* board you can create.
> (photo plotters do not have this precision, and the coordinate errors aremainly due to the board manufacturing process,
> not the limited precision of pcbnew coordinates)
>
> If the problem is just display coordinates in inches or mm, no need to rewrite Kicad and the file formats

Alright, alright, you've convinced me, now is not the time to change the file formats (or the IU), instead, that will come when new features demands it.

> --
> Jean-Pierre CHARRAS

Øyvind.