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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
