kicad-developers team mailing list archive

[Maciej Suminski <maciej.suminski@xxxxxxx>]

GAL tools do not perform any unit conversion. They work with the
internal units, whatever they are, by calling Get/SetPosition() methods.
I doubt there are other hardcoded conversions in the GAL code.

The problem with the hardcoded scaling you see in the patch (and as a
matter of fact, in the original code) is caused by WS_DRAW_ITEM_LIST
demanding a scaling factor (SetMilsToIUFactor() method). When I was
writing the code, I was really confused by the #ifdefs in
convert_to_biu.h. Even once I understood them - I still could not use
any of them, as libcommon does not define IU_PER_MILS.

To sum up: I am not proud of the existing code, but I could not find any
other way to implement this correctly. I agree there is a problem to be
solved, but I would rather fix it at its root, instead of looking for
other workarounds.

Regards,
Orson

On 03/17/2017 01:40 PM, Wayne Stambaugh wrote:
> On 3/17/2017 3:06 AM, jp charras wrote:
>> Le 17/03/2017 à 00:32, José Ignacio a écrit :
>>> eeschema uses mils, which are exactly 25400 nanometers, eeschema can be losslessly converted to
>>> nanometers. Another advantage of using nm in eeschema would be that it would be possible to use
>>> round metric quantities (right now it's impossible and confusing as numbers are rounded to the
>>> nearest mil) while being able to open older schematics losslessly.
>>
>> But Gerbview uses 10 nanometers.
>> 1 nanometer in Gerbview creates integer overflow in some gerber files, which can use large
>> coordinates (usually due to a large offset when plotting files).
>>
>> Eeschema has other constraints.
>> Especially, you cannot easily mix mils and mm for the working grid, because items are connected when
>> the end points are at the same location (no magnetic pin).
>>
>>
>> A correct handling of the actual internal units is for me the better (and the easier) way.
> 
> This is going to have to be done at some point anyway or none of the
> "common" tools that do any unit conversions will function properly
> outside of Pcbnew.  As I said before, I'm OK with merging this patch
> since this issue already exists with other tools but this just adds one
> more place where it will have to be fixed when the common tools are used
> in eeschema or gerbview.
> 
>>
>>>
>>> On Thu, Mar 16, 2017 at 2:16 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>
>>>
>>>     On 3/16/2017 3:03 PM, jp charras wrote:
>>>     > Le 16/03/2017 à 11:21, John Beard a écrit :
>>>     >> Hi JP,
>>>     >>
>>>     >> Thank for checking this. Internal units always confuse me, since
>>>     >> they're always different and nothing in common can ever use anything
>>>     >> to do with IUs, as they're only defined in some end executables.
>>>     >>
>>>     >> How should this be done correctly?
>>>     >>
>>>     >> Cheers,
>>>     >>
>>>     >> John
>>>     >>
>>>     >
>>>     > IUs are not very easy to handle, and currently I am not very happy by the way they are handled.
>>>
>>>     Me neither.  I've never been a big fan of compiling the same source code
>>>     file multiple times (see include/convert_to_bui.h) depending on a
>>>     definition specified at compile time.  I would much rather see some type
>>>     of abstract class be used to define the app specific internal units.  Of
>>>     course you would have to modify the tools to use this object to provide
>>>     the proper internal units.
>>>
>>>     >
>>>     > About the GAL layer, sorry, but I am not a GAL specialist.
>>>     > However I just know this issue is serious and must be solved.
>>>
>>>     This makes me reluctant to merge this patch even though it sounds like
>>>     this issue already exists elsewhere in the "common" tool framework.  It
>>>     also means that none of the "common" gal tools that use nanometer units
>>>     will be usable in the schematic editor and no I don't think nanometer
>>>     units make any sense for the schematic editor.
>>>
>>>     >
>>>     > Until now, GAL was used only by Pcbnew.
>>>     > Unfortunately, in a few places, I saw a conversion to nanometers using fixed scaling factor.
>>>     > (A golden advice I learned when writing Kicad code: do not use a fixed scaling factor in code)
>>>     >
>>>     > Now GAL is very near to be used by other applications.
>>>     > Conversion to nanometers just by using a fixed scaling factor is therefore a bug, and from my point
>>>     > of view, even in Pcbnew.
>>>     > Who know: we could change one day the internal unit value. It already happened.
>>>     >
>>>     > I just leave guys who have a good knowledge of the GAL code taking the best decision.
>>>     >
>>>     > Thanks, John.
>>>     >
>>>
>>>     _______________________________________________
>>>     Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>     Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>>>     More help   : https://help.launchpad.net/ListHelp <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
>