kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>