kicad-developers team mailing list archive
Mailing list archive
Re: Converting KiCAD to metric units: The approach
В сообщении от Воскресенье 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
> - 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
--- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61