kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit :
> Hi Johannes,
> 
> Thank you for your suggestion but the internal units for each format
> were chosen for a specific reason.  There really is no justifiable
> reason to change them as they have been carefully selected based on the
> requirements of the objects they represent.  Conversion code is provided
> for each internal unit so plotting to standard units such as
> millimeters, inches, etc is trivial.  I'm not opposed to adding support
> for changing the plot units.  I am opposed to changing the internal units.
> 
> Cheers,
> 
> Wayne

I fully agree with Wayne.

Why these different units (I am talking only about coordinates, not angles):
Pcbnew uses 1nm.
Due to the fact a "int" is widely used in code for many calculations, the actual size of a board is roughly
INT_MAX / 1.414 with a margin: say INT_MAX/2.
Why INT_MAX / 1.414?
Because we need to calculate distances (and inside a square, the max dist is INT_MAX / 1.414) and we also
need margins.
So I am expecting 1 nm allows boards up to 1 meter length, not much more.

>From the max bord size  POV, 10nm is a better choice for board max size, but creates rounding issues during conversion
between inches and mm (see tools/test-nm-biu-to-ascii-mm-round-tripping.cpp)

*Do not expect* using a 64 bit coordinate: many calculations already use int64 for intermediate calculations using int32 coordinates.
Especially our Clipper polygon library.

Gerbview uses 10nm because some Gerber files use large coordinates and the conversion between inches and mm
is not as important as in Pcbnew.

New Eeschema uses 100 nm because this is also a good choice for a schematic (some users use very larges sheet sizes)

> 
> On 2/13/20 9:32 AM, Johannes Pfister wrote:
>> The KiCAD code uses all kinds of different units for distances.
>> Amongst other things I found:
>>   nm: pcbnew internal units
>>   10nm: Gerbview internal units
>>   100nm EEschema internal units
>>   1um: PL-Editor internal units
>>   0.1mil (2.54um): SetViewport
>>   1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils
>> And the native File formats use mm (pcbnew) and mil (EEschema).
>> Something like SVG exports in 0.1 mil steps. I think that this is not
>> very consistent and something like a PLOTTER class needs to handle
>> different IU-sizes.
>>
>> My idea is to rewrite the internal units so that nm are used
>> everywhere inside the source code, and only parts that write or read
>> files and display data to or read data from the user should convert it
>> to another unit system. I don't want to change any file formats.
>> That would make it a bit more straightforward, more consistent, metric
>> and an SVG-Plotter would use a metric step size. The disadvantage
>> would be that there would be an about 2m or 4m limit in every
>> direction, assuming int is 32 bit, which is AFAIK true for all
>> platforms KiCAD current supports.
>>
>> Before i rewrite code, can you say what you guys think about it?
>>
>>
>> Johannes Pfister
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS