On Wed, Nov 23, 2011 at 11:30:39PM -0600, Dick Hollenbeck wrote: OK, so typically an 'int' in decimils (now); will become nanos or 10nanos when we'll decide.
> *) Snap grid. A snap grid is a subset of the full set of possible XY > coordinates Like in 'dimension/grid size', expressed in BIUs, right? > *) Metric Board. This is a pcb board that has a great number of coordinates > and > distances that happen to be some multiple of the BIU that is also a multiple > of > a metric engineering unit such as micrometers. > > *) Imperial Board. This is a pcb board that has a great number of > coordinates and > distances that happen to be some multiple of the BIU that is also a multiple > of > an imperial engineering unit such as mils or inches. Why do a distinction? when measured in nanos an imperial board become metric (by the definition of the current inch). It's more a user interface issure (the mm/inch buttons). > a) It is OK to modify the board file format in order to handle the BIU change. Necessarily, unless you want to do fractional decimils (the horror!) > b) Boards saved on disk in the new format will not be readable using old > software. > > c) Since we have no backwards compatibility obligation, we can make > significant > changes to the file format while we have this disruption opportunity. A 'compatibility mode' *could* be added where you 'round' the coordinates to decimil. This way you could keep the basic file structure (you need to keep backward *loading* compatibility, otherwise I'll linch you personally :D); so instead of: DS 120 130 140 150 you could have DS 1200* 1300* 1400* 1500* where numbers would be suitably scaled and * would be a 'suitable' marker. Then define an I/O routine to recognize the marker and you're ok. Or simply flag in the header that the unit is BIU instead of decimils and keep the same string representation (think about *MOIN and *MOMM in gerbers) > 1) Is it not possible that the board could be saved on disk using engineering > units other than the BIUs? A simple way is indeed to simply use BIUs instead of decimils; a slightly more complex one is to accept things like 10mm 11mi 12nm 13in like my parser for edit boxed. That would somewhat useful for hand edited/generate modules, in particular. But I'd say only *useful*, not required. > 2) Once the BOARD is in RAM, is it not possible that all objects within the > BOARD* object use BIUs as their spatial coordinates and BIUs as units of > measured distances? In ram only BIU, don't shoot yourself in the foot... think about TeX, inside it's everything in scaled points (1/65536 of pt), fixed point too (a big design issue in TeX was that in these days FP wasn't standardised and Knuth wanted repeatability of the output...) > 3) Is it not true that the main difference between the user interface in play > while working on a metric board vs. an imperial board, is the grid snap > distance > (and various computer screen fields and menus) ? Only UI (in fact only edit boxes and the status bar); I can confirm that because I sweeped the code during the input box patch. The only nonstandard handling IIRC is during grid dimension processing and some report (like drill tables); as I said before: all BIU, inches and mm are only a (superficial) UI feature. > 4) If sufficient resolution is preserved, is there not some advantage in > disconnecting the chosen engineering units in a saved BOARD file from the BIU? > (On the theory that if the BIU needs to be changed again in the future, that > you > do not also have to change the BOARD file format, a situation we currently > find > ourselves in?) Put the BIU in the header, like BIU = 10nm or something. But I think it complicates unnecessarily the format. OTOH MicroStation did this until a few versions ago (when AutoCAD required an FPU, MicroStation was still fully fixed point!); this could be another *useful* but not required thing in my book (still, it should be easy to implement). > 5) Is is not simply a matter of scaling other engineering units like > millimeters > when loading a BOARD file into the RAM resident form where BIUs pertain? In > reverse direction for disk saves? Like in my example 10mm 11mi and so on you mean? > 6) Is it not simply a matter of scaling to other engineering units like > millimeters or mils when exporting a RAM resident BOARD (of course using BIUs) > to other formats such as gerbers? Exactly, that's the 'reporting' issue I said before. > 7) Which items among 1) through 6) are new? Sorry, didn't get the question... all of this IIRC were already been proposed on the list. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
