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