kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/13/2012 02:04 AM, jean-pierre charras wrote:
> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
>> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
>>> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
>>>> This new format looks great, I have a few comments/questions
>>>>
>>>>       1) in some spots like module pads there is (net<nutNum>  <netName>) and in other
>>>> spots like track segments it only has (net<netNum>).
>>>>       2)What do the edge tags represent in the Module
>>> Exactly.  It might not be the first English tag that comes to mind for this. eh?  I'm not
>>> even sure these are limited to "edges".
>> This is one of those areas where I am relying on the knowledge of
>> someone who know about the BOARD_ITEM internals that I do.  If there is
>> a more descriptive name or way to present this information, I am
>> certainly open to suggestion.
>>
>>>>       3)Draw arc has tags start and end.  I'm not sure if this has changed, but the file
>>>> format before this held onto the center of the arc, and an endpoint of the arc...
>>>>          The file format definitions also say it holds onto the starting point and the
>>>> ending point, which caused a lot of headaches when I wrote my file format converter
>> I've saved the object information as defined in the current file format
>> document as closely as possible.  If arcs are defined this way in
>> current file format, then they will be defined that way in the new file
>> format.  Otherwise, some transformation will have to be made when
>> reading the file.
>>
>>>>       4) What are the two (at) tags in module_text for? why not only 1
>>>>                Is one a position relative to the module and one a position relative to
>>>> the board?
>> Good question.  It appears that TEXTE_MODULE::m_Pos0 which is relative
>> to the anchor position of the module is the only position saved in the
>> current format and EDA_TEXT::m_Pos is the absolute position on the board
>> which I'm guessing is determined from the position of the module.  I'm
>> not sure why it was done this way.  Is there any reason not to dump
>> TEXTE_MODULE::m_Pos0 and just use EDA_TEXT::m_Pos?
> All items inside a MODULE have a position on board (m_Pos, m_Start ...
> and the corresponding parameter relative to the module anchor.
> The reason is m_Pos *should always* be calculated from m_Pos0 after a rotation transform,
> due to rounding issues.
> Only 90 degrees rotations do not have rounding issues.
> Therefore, after some rotations (for instance 10 rotations each for 9 degrees),
> when using only m_Pos, there is a significant error between one 90 deg rotation
> and 10 x 9 deg rotations.
>
> Because absolute coordinates are calculated from relative coordinates,
> only relative coordinates need to be saved on files.
> (absolute position and rotation of the MODULE are known)
>
> I have not a strong opinion about how flipped footprints should store relative coordinates,
> but I am thinking the stored values (coordinates, text mirroring, layers and layer masks) could be
> stored as non flipped values, i.e. a flipped footprint is "un-flipped", saved and flipped (restored).
> Actual values will be restored after reading the file.
>
> Eeschema stores (in lib) shapes in position 0, orientation/mirroring 0,
> and stores the geometric transform for each component.
>
> This is perhaps not a bad idea to do the same in Pcbnew.
>
> Some other files format use the same thing,
> and this could make file format conversion more easy.



We seem to have no extraneous C++ objects.  And this conversation should not diverge into
changing C++ objects, but should remain largely focused on file format.


However, I will not let go of the importance of this format's effect on our ability to
perform clipboard operations later.  From day one going back 4-5 years ago, this has
always been a main objective of the s-expression format of mine.


Within a BOARD C++ object, there are two kinds of text C++ objects, two kinds of line C++
objects, two kinds of arc objects, etc, with one relative to the board and one relative to
the module/footprint.  This is status quo.


We need:


1) to differentiate these later when pulling them off the clipboard,
2) to create different C++ objects at file load and at clipboard parsing time.
3) to augment them with different trailing s-expression elements.


So I suggest:

pcb_text, pcb_line, pcb_arc, pcb_circle, pcb_poly


fp_text, fp_line, fp_arc, fp_circle, fp_poly


This provides symmetry in naming yet provides the freedom to give different trailing
attributes in the expression, again, used both for *clipboard* and *.kicad_pcb file.

It also reduces the number of parsing tokens down from (draw line ....)  to (pcb_line ...)



Dick