I would also prefer the option to simply store 3D units in inches; we just need to document this. Truncation will not be a problem for 3D models; if the models move by 0,01mm no one will care (or if someone does care then they need to go back to engineering school). I think this is a case where history has set restrictions on what we can do and there's no value in making a change since it has terrible implications on the footprint libraries.
- Cirilo On Thu, Nov 9, 2017 at 8:48 PM, Oliver Walters <[email protected]> wrote: > 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
