kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Safer because we’ve been writing them out like that for some time.  Maybe someone has some huge hack that uses fixed-length regular expressions to parse them or something.  

In the absence of a spec, the examples are what people use.

I’m not convinced this is the best plan either — but I am convinced it’s the safest.

Cheers,
Jeff.


> On 24 Dec 2019, at 19:29, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
> 
> Why is B safer? To me, B sounds riskier as there is a chance we are throwing away data. I'm not in favor of implementing B without a clear spec (and I guess Ucamco would need to be involved) on what guarantees can be made.
> 
> Right now, we implement B based on some apparently arbitrary assumptions about what data can be thrown away. Re-implementing the current behavior in the new library would certainly be possible, I'm just not convinced that it's the best plan.
> 
> -Jon
> 
> On Tue, Dec 24, 2019, 13:54 Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> wrote:
> Safest would be (b).
> 
> We could probably do something pretty dumb (ie: set a single value in the JSON printer which it uses for precision).
> 
>> On 24 Dec 2019, at 15:22, Jon Evans <jon@xxxxxxxxxxxxx <mailto:jon@xxxxxxxxxxxxx>> wrote:
>> 
>> Hi all,
>> 
>> The Gerber job file specification[1] says that the format follows the JSON standard, and doesn't say much else about numeric value storage.
>> 
>> But, in the examples in that spec, decimal (floating-point) values are all truncated with only a few digits after the decimal point.
>> 
>> The manual JSON generation code that exists today follows along these examples, truncating floating-point numbers using formatting like %.3f and so on.  Now I'm working on switching us over to using a library for this JSON generation, but it will output floating-point values as doubles without any such truncation.
>> 
>> For computer software reading these job files, I would guess this has no impact.  But for humans opening up the file, they may find that the numbers stored don't match their expectations.
>> 
>> What should we do about this?
>> (a) nothing, storing doubles in the file is fine
>> (b) find some way to manually truncate/round values to some precision, but still write them to the file as "decimals" -- if so, what should the spec be for this rounding / truncation?
>> (c) something else?
>> 
>> Best,
>> Jon
>> 
>> [1] https://www.ucamco.com/files/downloads/file/209/the_gerber_job_format_specification.pdf <https://www.ucamco.com/files/downloads/file/209/the_gerber_job_format_specification.pdf>_______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>