kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

Le 12/04/2012 23:57, Dick Hollenbeck a écrit :
> On 04/12/2012 01:53 PM, Wayne Stambaugh wrote:
> > 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.
>
> class EDGE_MODULE is derived from DRAWSEGMENT and comes in types
> S_SEGMENT, S_CIRCLE, S_ARC, S_POLYGON.
>
> So it is basically a graphical line, circle, arc, or polygon.
>
> Basically a "graphic", so that word is one candidate.  It is not confined to the module's
> edge, but is often used to delineate the bounds of the footprint.
>
> However you would use one of these to designate PIN 1 on the footprint.
>
> It is nearly the same discussion we had about (draw line  ....) before.
>
> You could go with "gr_line" for S_SEGMENT, "gr_circle" for S_CIRCLE, etc.
>
>
> The discussion about why not (text..) for both BOARD and MODULE is almost the same
> discussion about (draw...)  [now edge] for BOARD and MODULE.
>
> There is an argument to try and unify them.
>
> There is also an argument to keep in mind some solution for the case where you pull this
> text off the clipboard, and now you have to know whether it is for a BOARD or MODULE, and
> one way to do this is to have unique keywords, but not the only way.
>
> Off the top of my head I do not know what class EDGE_MODULE does differently than DRAWSEGMENT.

EDGE_MODULE has m_Start0 and m_End0, useless in DRAWSEGMENT, to handle MODULE rotation transform
without cumulative rounding errors.

> > > >       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.
>
> If it can be or is readily computed, then perhaps we don't need to save it?
>
> Jean-Pierre?  (I am too busy to check code right now.)

DRAWSEGMENT uses internally only arc center point, arc starting point, and arc angle.
arc ending point is calculated on the fly, when needed.

Arcs are always a nightmare.
Some functions (graphic libs for instance) use starting and ending points coordinates,
some uses start angle and end angle.
Angles are sometimes CCW, sometimes CW.

Y axis can be from bottom to to, or top to bottom.

And so on...

So when working on arcs, mainly in file format import/export,
"lot of headaches" is an understatement,
and unfortunately the pay is low.

Therefore:
Arc ending point is not needed in new file, but could be stored like a comment.

--
Jean-Pierre CHARRAS