Mark is correct: The question is about whether or not we need to apply specific rounding/truncation (which no third-party JSON library does)
On Sat, Dec 28, 2019 at 8:37 AM Mark Roszko <mark.ros...@gmail.com> wrote: > But that 1.600 is not a double/floating number, it truncated from the > double of 1.600000000000000088817841970012523233890533447265625 > > The entire complaint I believe is when it comes to serializing to JSON > in 99% of software of all languages, you do not apply custom > formatting to convert doubles to having less digits, you literally > store the data type as is for what's considered a JSON "number". > Otherwise we should be storing the float as string and applying the > custom formatting in the conversion to string. > > On Sat, Dec 28, 2019 at 8:01 AM jp charras <jp.char...@wanadoo.fr> wrote: > > > > Le 24/12/2019 à 21:43, Jon Evans a écrit : > > > OK, so both the JSON format itself and the Ucamco gerber format (which > > > is not necessarily the same as the job file format, but hey) specify > > > storing doubles. > > > But, the examples in the Ucamco doc, and KiCad itself, do not store > doubles. > > > > > > I have to imagine that the gerber job file format is so new that it > > > isn't entrenched in anyone's workflow yet, and if it is, they are not > > > relying on this quirk of KiCad's implementation (but anything is > possible). > > > The only way to get KiCad's behavior is through manual formatting of > > > JSON, so anyone who writes software that parses job files through a > JSON > > > parsing library is going to have those values "upcasted" anyway. > > > > > > My personal opinion is that we should bite the bullet and change the > > > behavior to comply with the standard (i.e. store doubles), and also > > > suggest to Ucamco that they revise the job file spec to be more > explicit > > > about this. > > > > > > Perhaps JP should weigh in on this as well. > > > > > > -Jon > > > > Sorry for the delay. > > > > I am unsure to understand the meaning of > > "KiCad itself do not store doubles" > > (in gerber job files) > > > > A line like: > > "BoardThickness": 1.600, > > > > stores a double: > > AFAIK, "1.600" is of course a floating number, and also a double, not > > an integer. > > > > In job files, most of values (board sizes, layers thickness, clearances) > > are "mechanical" values. > > > > A reasonable precision is the micron for this kind of parameters. > > > > No need to use nanometers. > > So values are written using 3 digits for the mantissa. > > > > Using the notation: > > "BoardThickness": 1600e-3, > > is perfectly valid, but useless and less readable. > > > > FYI, using 6 digits (1 nanometer) in other Gerber files is needed to > > avoid coordinates truncation. > > > > 3 digits is certainly enough to fabricate a board. > > Unfortunately, truncation slightly modify polygon coordinates, and this > > truncation can (and frequently does) create self intersecting polygons. > > (self intersecting polygons are illegal). > > > > -- > > Jean-Pierre CHARRAS > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > -- > Mark > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp