If the Ucamco specification calls out JSON as the file format, then we should respect the JSON file formatting regardless of whether it's ugly or not.
Cheers, Wayne On 12/28/19 9:02 AM, Jon Evans wrote: > I understand that point of view, but how do we determine what is > "reasonable"? > The Ucamco spec does not state anything about it, they just refer to the > JSON spec. > If we were to follow the JSON spec, we would not round or truncate. > > So I guess what I am asking is, if people think it's important for > Gerber job files to be human-readable and look "reasonable", can we make > some effort to get that into the spec, so that all software will do it > the same way and it won't be a case of KiCad doing one thing and other > tools doing a different thing, because there is no standard? > > -Jon > > On Sat, Dec 28, 2019 at 8:58 AM jp charras <jp.char...@wanadoo.fr > <mailto:jp.char...@wanadoo.fr>> wrote: > > Le 28/12/2019 à 14:37, Mark Roszko a écrit : > > 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. > > OK. > > I am thinking we have to use a reasonable and readable notation (like in > all our kicad files). > > To encode a board thickness, 1.600 is readable. > 1.600000000000000088817841970012523233890533447265625 is just ridiculous > (for any value in a config file). > > > > > On Sat, Dec 28, 2019 at 8:01 AM jp charras <jp.char...@wanadoo.fr > <mailto: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 > <mailto:kicad-developers@lists.launchpad.net> > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto: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 > _______________________________________________ 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
