kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 21/11/2018 à 20:35, Wayne Stambaugh a écrit :
> On 11/21/2018 2:18 PM, Simon Richter wrote:
>> Hi,
>>
>> On 21.11.2018 20:02, jp charras wrote:
>>
>>> what do you mean by:
>>> "that the entire code uses nanometers as internal units
>> That would be the goal, to use the same internal unit everywhere.
>> Nanometers make the most sense, because of the metric/imperial
>> conversion issues you mention.
>>
>>> In Pcbnew, one nanometer is used mainly to avoid any conversion issue
>>> between inches and nanometers.
>>> Without this constraint, 10 nm will be better.
>>
>> Hm, 1mil is 25400nm, so we could even go to 100nm without introducing
>> conversion issues. Would that work for all apps?
> 
> This would break pcb files so nm has to stay for board and footprint
> files.  I was planning on using 100nm for the new schematic and symbol
> file formats since it seems to me that we really don't need any more
> absolute positional accuracy than that.

Hi Wayne,
10 or 100nm looks like a good choice for me.

@Simon,

The 1 nm for Pcbnew was not chosen without a very good (read: mandatory)
reason by Dick Hollenbeck when he worked on the internal unit change in
Pcbnew.

Trust me:
A lot of time was spent about this choice.

See for instance tools/test-nm-biu-to-ascii-mm-round-tripping.cpp for
instance to test issues that are encountered by too large internal units
when converting a value from mm to inch and inch to mm.
* From the point of view of working area size, 10nm is the best choice
* From the point of view of mm to inch and inch to mm, 1nm is the best
choice

The 10nm internal unit was chosen by me for Gerbview because the 1 nm
was too small to handle large coordinates, and the mm to inch and inch
to mm conversion issue is not a problem in Gerbview.
These large coordinates can be found for very large boards (especially
flex) or when the coordinates origin is very far from 0,0 (I saw that in
a few .gbr files)

> 
>>
>>> By the way, I am pretty sure the the gtk3/Cairo overflow issue is not
>>> inside Kicad.
>>
>> Indeed, that is a Cairo problem, but I tried to debug this with -ftrapv,
>> and found that we have surprisingly many integer overflows within KiCad.
>>
>> They seem to be mostly harmless, but from a code quality point of view
>> I'd also like to see them gone.
> 
> These absolutely should be flagged and fixed whether they are harmless
> or not.  This is just a good coding policy.
> 
>>
>>    Simon


-- 
Jean-Pierre CHARRAS