(2019-04-04, 7:36)Lutz Gehlen Wrote: More importantly, what does "making them official" mean for other editors/viewers? Does it mean for example that an editor that decides to implement snapping should do it this way instead of inventing its own meta commands? For that maybe an "official recommendation" would be sufficient instead of making it part of the standard. Or does it mean that every standard-compliant editor has to support these commands?
It is clear that Roland has put _a lot_ of work into these features. Requiring the authors of every other software who want to be compliant with the standard to do the same would be a substantial obstacle. I think it is a great advantage of the ldraw file format that it is so simple to implement and most advanced features are realized via optional meta commands. These issues could be mitigated if the official standard would come with an official reference implementation, i.e. an open source and platform-independent library for PATH_* and SNAP_* commands. Only Roland can tell how much work it would be to extract this functionality into such a library and whether he would be willing to do so.
Part snapping support would be optional. It doesn't make since for every editor to have to support it (LDView is a prime example). The goal is to standardize how snapping information is encoded. SR3DBuilder had part snapping as well and when the author of that program passed away, his method also died. Roland has the benefit of having a robust and currently in use method to build off of. The META's are just information, how a future editor developer chooses use that information to implement the snapping is up to them.
Flexible part META would also be optional since the generated code will be included in the part. Once again, the goal is to standardize how we encode the information.
(2019-04-04, 7:36)Lutz Gehlen Wrote: Another question would be what this change means for parts authors. Will they be required to provide snapping information? My knowledge of parts definition and snapping information is so limited that I have no idea what that would entail.
My opinion and desire is that snapping info be in a parallel library with less stringent review requirements. This allow someone more proficient to add the snapping info and doesn't force a part onto the PT for a snapping info update. Due to primitive use, much of this info can be added simply by updating primitives. If a part author chooses to supply it with a new part, great. However, if someone updates an official part that affects the geometry (rare) then they would also have to update the correspond snapping info.
Again, all of this is my desire/opinion, not an official position on implementation.