JP, I think that 3) is the better option, because it preservers PCB file compatibility (as long as the offset is zero). Any time the PCB is saved, the (at (xyz 0 0 0)) gets written.
You are also correct that none of the official library footprints have a defined offset. This is why i have never encountered this before. On Fri, Nov 10, 2017 at 7:09 AM, Oliver Walters < [email protected]> wrote: > I like 2) or 3) - I think that a major release is a good time to fix such > a bug. > > Would you like me to add a patch implementing one of these options JP? > > On 9 Nov 2017 23:33, "Kristoffer Ödmark" <[email protected]> > wrote: > >> Currently the footprints arent compatible anyway i guess, they support >> more than 4.07 footprints do. So option 2 is my preferred solution. >> >> On 11/09/2017 12:51 PM, jp charras wrote: >> >>> 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. >>> >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
