← Back to team overview

kicad-developers team mailing list archive

Re: Question about gerber job file numeric format

 

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.charras@xxxxxxxxxx
> <mailto:jp.charras@xxxxxxxxxx>> 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.charras@xxxxxxxxxx
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >> 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@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
> 


References