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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
