kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
> 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

Sounds reasonable.  I'm assuming fp is short for footprint.  If we drop
the module prefix from the file format, I think we should internally
rename all things MODULE to FOOTPRINT for the same symmetry reasoning.
This gives developers a clearer understanding between the file format
and the objects they are related to.  If we keep module concept in
source code and footprint in the file format, that will just add to the
confusion.  A simple global search and replace can resolve this issue.
If no one objects, I'll go ahead and rename the board objects when I
change the s-expression token for these objects.

Wayne

> 
> 
> 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
> 
> 
> 
> _______________________________________________
> 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
>