However, doing so changes the displayed origin of every other component, and getting the grid origin back to its original location is a pain. It's easiest to set the grid origin to be the first such object and the grid spacing to the specified spacing, then all following objects fall on the grid. I can also see an argument for changing the file positions to drill-origin- relative, but I'm ambivalent about that.Īs can be seen in my patch series, I started with Grid Origin relative coordinates but found this to be problematic.Ĭonsider the situation where you want to place a series of holes/vias/whatnot in a line on a specific spacing. I believe this would be a mistake as it just complicates the UI and the file-relative positions have little value to the user.įor 6.0, I would recommend we change the GUI positions to grid-origin- relative. One bug report suggests adding textboxes for grid-relative positions to the existing textboxes for file-relative positions. There's no particular value in this, while there would be /considerable/ value in presenting them relative to the grid origin. When locations are edited through the UI, they are presented relative to file origin. Conceptually we think of this as just a grid origin, but many of our users think of it as the editing/display origin (which, to be honest, makes more sense). ![]() ![]() We also have a grid origin, which is user settable. But conceptually one could make an argument that it should set the origin for /all/ file values, not just drill file values. I suspect this is mostly legacy, as most manufacturers are happy enough without one. We also have a drill origin, which is user settable. Essentially all it does is tell us where to draw the page boundaries and page frame. It's absolute value is somewhat immaterial as most board houses will use the edge cuts to position the footprints. We currently have a file origin, which is fixed. ![]() There have been some discussions in bug reports and on forums regarding the various origins.
0 Comments
Leave a Reply. |