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 <j...@craftyjon.com> 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 <j...@rokeby.ie > <mailto:j...@rokeby.ie>> 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 <j...@craftyjon.com >> <mailto:j...@craftyjon.com>> 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@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
