kicad-developers team mailing list archive

[lajos kamocsay <panka.nospam@xxxxxxxxx>]

Hi Wayne-


I've had a conversation with Dick, and he asked me to clarify my
suggestion about standardizing the transformation data.

Standardizing would save you work and debugging time because you would
only need to write the encoder and decoder (parser) once. Instead of
every object taking care of the work, they could just call two
external functions (I don't have the code with me, but let's say
S_EXPR::EncodeTransformation() and S_EXPR::DecodeTransformation()).
The same functions could read/write transformation data for modules,
pads, polygon points etc.

As a side effect, the data files would be easier to read and write.
And I don't necessarily mean footprint makers, but opening the brd
files in emacs. But this is just bonus, the biggest win is less coding
and more decoupling.

You don't need to pick 1d vs 2d vs 3d vectors. It can easily be a
mixture, for example:

(object
  (position (vector2 1 1))
  (rotation (vector1 1))
  (scale (vector1 1))
)

If certain properties are default value, you might not even need to
write them (no rotation, 100% scale):

(object
  (position (vector3 1 1 1))
)

You could also separate out the vector encoder and decoder functions,
like S_EXPR::EncodeVector3() and S_EXPR::DecodeVector3(). (Again, I
don't have the code with me, so class and function names are just
examples, and possibly this is how it's already implemented.)

Naming is a secondary issue, point3 vs vector3 vs xyz doesn't matter
much (although point or vector seems a bit more generic and reusable).




Thanks-
-lajos




On Mon, Apr 9, 2012 at 10:45 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> 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
>>>
>>