On 4/8/2012 12:38 PM, lajos kamocsay wrote: > Hi Wayne- > > > The new file format looks awesome. Very simple and readable. > > Would it be possible to standardize the transformation data? Currently > there seems to be a couple different formats, some examples: > > (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) > (width 0.127)) > > (size 1.016 1.651) > > (at -1.524 0) > > (at (xyz 0 0 0)) > (scale (xyz 0.17 0.16 0.16)) > (rotate (xyz 0 0 0)) > > I think having a standard format would be very helpful for external > utilities reading/writing kicad data, like: > > (object > (position xyz(1, 1, 1)) > (rotation xyz(0, 0, 0)) > (scale xyz(1, 1, 1)) > )
Lajos, Thank you for your comments. I carried over the "at" token from the new schematic and schematic library file formats. For 2D transforms I want to keep this notation so that it is the same between the schematic and board file formats. I'm fine with using a different notation for 3D transforms. My original though was just to use (scale X Y Z) since this is inside a 3D object it may clear enough to the user that 3D transforms require XYZ. > > Or if you want shorter names, you could use the p/r/s letters for > position/rotation/scale or t/s/r for translation/rotation/scale and v3 > for a 3d vector: > > (object > (t v3(1, 1, 1)) > (r v3(0, 0, 0)) > (s v3(1, 1, 1)) > ) I want to avoid abbreviations that are not obvious. The file format must be human readable not developer readable. Most of the developers will know what t/r/s means but a normal user shouldn't be expected to wade thought the source code to find out what t/r/s means. The goal is the minimum verbosity to achieve human readability. Thanks, Wayne > > Although nowadays storage is usually not an issue, and the file can be > optionally compressed with zlib. So probably the more verbose names > are better. One of the small boards I saved was 28k in the old format, > 52k with s-expr, 6k s-expr compressed. > > Another alternative would be a 3x3 matrix: > > (object > (transform matrix(1, 1, 1, 0, 0, 0, 1, 1, 1)) > ) > > > > Thanks- > -lajos > > > > > On Sat, Apr 7, 2012 at 2:58 PM, Miguel Angel Ajo Pelayo > <[email protected]> wrote: >> nice!!!, I will start trying it. >> >> >> 2012/4/7 Wayne Stambaugh <[email protected]> >>> >>> Oops! To be able to save to the new file format you must add >>> -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON and -DUSE_PCBNEW_NANOMETRES=ON when >>> invoking CMake in order to build the new code. >>> >>> On 4/7/2012 2:09 PM, Wayne Stambaugh wrote: >>>> It took long than I anticipated (doesn't always?) but I just committed >>>> the code to allow saving board files to the new s-expression based file >>>> format. I would like as many folks as possible to save their favorite >>>> board file using File->Save As to the new format and take a look at the >>>> result. My goal is to get the final file format nailed down as quickly >>>> as possible. There are few caveats: >>>> >>>> * I still have to convert angles to degrees from the current tenths of >>>> degrees so please ignore the fact that 270° is saved as 2700°. This fix >>>> is coming soon. >>>> >>>> * The lead developers have decided to drop support for the old segment >>>> filled zones (SEGZONES) which have not been used in quite some time. I >>>> will be adding a dialog warning the user that they will need to refill >>>> their zones using the current polygon filling. I doubt this will effect >>>> very many users but I could be wrong. >>>> >>>> * I rearranged the object ordering slightly compared to the current file >>>> format. I moved the graphic items (items with no net connection) before >>>> the modules. This way all of the net connectable objects (modules, >>>> traces, zones, etc.) will be grouped together. >>>> >>>> Please take some time to look over the new format. If you find a token >>>> (key word) that is not clear, let me know so we can choose names that >>>> are as human readable as possible. Please keep in mind that the file >>>> size is going to increase dramatically over the current format so try to >>>> keep names as brief as possible while still maintaining readability. >>>> Also, if you find any indentation or other formatting errors, let me >>>> know so I can fix it. I will be working on reading the new file format >>>> over the next few days (weeks?) so I would like to wrap up the file >>>> format definition in a reasonable amount of time. Thanks in advance for >>>> you help. >>>> >>>> Wayne >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> >> -- >> >> Miguel Angel Ajo Pelayo >> http://www.nbee.es >> +34 636 52 25 69 >> skype: ajoajoajo >> >> _______________________________________________ >> 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
