kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #43160
Re: Question about gerber job file numeric format
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.roszko@xxxxxxxxx> 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.charras@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References