← Back to team overview

kicad-developers team mailing list archive

Re: Question about gerber job file numeric format

 

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> 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
> 
> 
> 


-- 
Jean-Pierre CHARRAS


Follow ups

References