← Back to team overview

kicad-developers team mailing list archive

Re: Internal units in the KiCAD source code

 

The plotting dimensions can be an option in the plot dialog.  I don't
want to force the plot units one way or the other.

On 2/14/20 6:30 AM, Johannes Pfister wrote:
> What about changing the plotter and page_info classes to metric? Like
> changing GetSizeMils() to GetSizeUM(), m_IUsPerDecimil to m_nmPerIU
> and MIN_PAGE_SIZE to MIN_PAGE_SIZE_UM? I say um because it is the
> largest IU (PL-editor) and m_nmPerIU could be an integer (AFAIK). That
> would make everything metric, avoid rounding errors for pages and pen
> sizes that are on a grid of 1 um or 10 mil, and it would avoid
> calculating the conversations factor to convert from metric to
> non-metric, only to then convert the conversations factor back to
> convert metric to metric, like it is done when starting a gerber plot.
> It would not limit maximum page sizes to a lower limit.
> Would you accept and welcome this or do you think this is a bad or useless idea?
> 
> Johannes
> 
> Am Do., 13. Feb. 2020 um 14:46 Uhr schrieb Wayne Stambaugh
> <stambaughw@xxxxxxxxx>:
>>
>> 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
>>
>> 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
> 
> _______________________________________________
> 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
> 


References