kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

В сообщении от Воскресенье 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