В сообщении от Воскресенье 26 июня 2011 00:11:46 автор jean-pierre charras написал: > Le 25/06/2011 13:19, Lorenzo Marcantonio a écrit : > > On Fri, 24 Jun 2011, Dick Hollenbeck wrote: > >> If the UI has to support imperial, then I think the files should too. I > >> would be willing to yield on this, but not because it is presumed to be > >> difficult to code and make work, only if it is truly not needed. > > > > You could easily adapt the UI routines for converting units to file IO, > > but then the underlying format should have the notion of 'measure with > > unit'. Sort of like in CSS. > > > > instead of (line 0 0 1000 1000) you could handle (line 0mil 0mil 100mil > > 100mil) > > > > No idea if it would actually be useful... > > I was away and busy last days. > > Like Dick and Lorenzo, I do not see the advantage to change coordinate type > from int to an other type like class LENGTH. Here are some topics involved > by an internal unit change from the current decimil to a smaller unit:
It seems the only way to prove my POV is to show... > > Changes in .brd files must not use an internal unit, but (like already > proposed) values like line 0 0 1000 1000 (if no unit: use default unit > (decimil): compatibility with old files or > line 0mil 0mil 100mil 100mil > line 0mil 0mil 100.0mil 100.0mil > line 0.0mm 0.0mm 100.0mm 100.0mm > The parser must accept all these notations, and obvioulsy values can be > saved in mils, mm or default unit (the default unit value is already > stored in .brd header files). I cannot realise what purpose such a rich set of notations should handle. It is just complicates both parser and generator. > > UI dialogs use very few functions to convert internal values to strings and > strings to internal values, and should be esay to modify. I am not sure > functions like mm2internalunit are needed in Kicad code. > > The more annoying points are due to the fact a smaller value like nanometer > will certainly create issues (overflow ) in some calculations and/or plot > and drawing functions: it should be catchable during debug process, and finally wrapped into fine geometry processing routines. > for instance: > - using very large coordinate values in draw functions need to select a > very small user scale value. I am pretty sure wxWidget draw function could > fail (at least under Windows) in this case ( have a look to > http://trac.wxwidgets.org/ticket/13284, (I spent a lot of time to report > this bug) and the patch file scale_error_patch.diff I uploaded to > understand how the actual draw scale is set in dc.cpp ) Please note I saw > draw issues due to large coordinates under Windows and Linux. This is the > main reason Kicad has built-in clipping functions It seems that best way is to do all the scaling/clipping inside, thus ignoring all the wx bugs and inaccuracies (i already fixed the box drawing as wx one is really inaccurate). > > - Some algorithms (inside and outside Kicad) can fail when using large > coordinates: an example can be found in functions that need to know if 2 > vectors are colinear: if they are colinear, the 2 slopes are equal. > Frequently, functions that compare the 2 slopes dy1/dx1 and dy2/dx2, > instead of use "if ( dy1/dx1 == dy2/dx2 ) ..." use the form: > "if( dy1 * dx2 == dy2 * dx1 ) ..." to avoid truncate issues. > Unfortunately, large coordinates create easily overflows inside this > kind > of functions. I don't think it is a great issue. :) > > I am not saying a smaller value like nm is not useable. > But it is 2000 time smaller than the current unit, and certainly this > change will show new issues. I am saying a work on very smaller values for > internal units must start by tests with draw functions, and other complex > functions (mainly relative to zones using Kbool and BOOST::Polygon and > tracks cleaning), and fix issues (if any) or choose an internal unit value > that works.. BOOST::Polygon is very fine but does not support arcs, which could be useful in pcbnew. -- --- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
