kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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

On Tue, Dec 24, 2019 at 3:35 PM <seth@xxxxxxxxxxxxx> wrote:

> The Ucamco "decimal" type is defined on page 40 of [1].  They define it as
> fitting into an IEEE double.
>
> I think keeping user-specified data would be desired and not truncate the
> value unless requested.
>
> Seth
>
>
> [1]
> http://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf
>
> On Dec 24, 2019 12:06 PM, Jeff Young <jeff@xxxxxxxxx> wrote:
>
> 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> 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> 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
> _______________________________________________
> 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
>
>
>
>
>