Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :
My 2 cents is that the headaches of storing values in mixed units, without indication of which unit
they are stored as is a huge drawback for readability of the saved files and for maintainability.
Also I think the proposed new tag offset is a good idea, since the libraries can be gradually
updated then. That the files cannot be opened by previous versions is a minor problem, since the
files cannot be opened by kicad 4.07 anyway already.
In fact, footprint files can be opened by 4.07 version, as long as they contain no round rect or
custom pads (should be most of files)
On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:
This requires a file version bump and code that tests for prior versions
before converting the units on read. At that point, the file will no
longer be compatible with prior version of KiCad. I'm not opposed to
this but I'm not sure it's worth the headaches it will cause.
On 11/08/2017 03:33 PM, Oliver Walters wrote:
What about a controversial idea:
Read "at" dimensions as inches, but new files write "offset" in mm.
This preserves read compatibility but fixes the units issue going forward.
<...>
There are 3 different things related to the anchor coordinate 3D shapes in Oliver's patch:
1 - coordinate units inside Kicad: they should be in internal units
(I do not remember if it is currently the case).
no problem.
2 - Display unit name in dialog: good enhancement.
3 - how to store this anchor coordinate in .kicad_pcb files.
There are 2 options:
opt 1 - use keyword "at" and store it in inches (current case). Certainly annoying because all other
coordinates use mm, but this is not a major issue.
opt 2 - be able to read "at" (inches) and "offset" (or perhaps "anchor") (in mm) and use offset as
new keyword: but it breaks compatibility with old (namely the recent 4.07) kicad version.
opt 3 - same as 2, but stores "offset" (or "anchor") *only* if it is not the default value (0 0 0).
AFAIK, the default value is the case of most (perhaps all) footprint files in our official repo.
in case of option 2, the parser should be (obviously) able to understand the keyword "offset" (or
"anchor") to prepare the future.
