pcb-rnd knowledge pool

Abstract: n/a

Use pcb-printf. There are different formats to consider, with different advantages and drawbacks. There are 4 recommended formats, each works without rounding errors:

1. Human readable unit with suffix and space: %.07$mH (e.g. 14.56 mm) This is the most human readable form, but it is the least script-processable one: a script needs to know all current (and future!) units pcb-rnd uses. If field separator is whitespace, the unit also falls on a separate field. The .07 part means print at most 7 decimal digits after the dot (always enough with nanometer precision) and truncate trailing zeros. The $ means print unit.

2. Human readable unit with suffix and no space: %.07$$mH (e.g. 14.56mm) Same as 1. but don't put space between the value and the unit. Makes it a bit less readable but keeps them together.

3. Fixed mm unit with float: %.07$$mm (e.g. 14.56mm) Being an SI unit, mm might be a good choice. With at least 6 digit precision it is guaranteed to not lose any bit of a nanometer value. A fixed unit makes script-processing easier.

4. save in nanometers, with suffix: %$$mn (e.g. 14560000nm) This gets all coords as integers, suffixed with the nanometer unit (nm) without spaces. This is a self-explaining, processable format.

What may look like a good idea but should not be done

A. Print coords without units. It may look like a good idea now and there may seem to be a perfect unit (like nm) to chose and it's all so obvious that printing the unit would be just too redundant... But this is exactly how unitless "centimil" ended up in the previous file format. A solution like this is not future-proof.

B. Using %mI - in theory exporting in the internal format is a good idea as it evades all possible rounding errors. However, it is not future-proof: the internal format may change. It's better to use a fixed output format and a conversion, even if it's an 1:1 conversion at the moment. So rather use 4. from the above list. It's also better to include the unit explicitly, for the reasons described in A.

C. any non-%m format: the internal representation of Coord may change; we already have 32 and 64 bit options so a simple %ld won't even work properly.

D. leaving off the %.7 or %.07 from the floating point output formats - the code will usually print to 2 digits by default, which will introduce rounding errors with most units. Whether trailing zeros are truncated or not has only aesthetic aspects.

E. using %mr - it's only for io_pcb in compatbility mode, see point A.

About how it is done in the .pcb format and for more background on each possibility, please read fmt_pcb_nano1 .