kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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
> <miguelangel@xxxxxxx> wrote:
>> nice!!!, I will start trying it.
>>
>>
>> 2012/4/7 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>>
>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>