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