kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

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:

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).

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:
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

	- 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 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..

--
Jean-Pierre CHARRAS