kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Wayne, regarding:

DRAWSEGMENT::Format(), it concerns me in two minor ways:

    case S_SEGMENT:  // Line
        aFormatter->Print( 0, "line (pts xy(%s) xy(%s))",
                           FormatBIU( m_Start ).c_str(),
                           FormatBIU( m_End ).c_str() );
 

a) I don't think this is s-expression, the xy(...) should be (xy ...)


b) It may be worth considering losing one token, namely the "(draw line"  might be
"(gr_line".  (Really, I am just trying to cover my ass.)  I don't want to be blamed for
the slow parsing speed later.   :)   Any reduction in another token that is simple like
this is worth considering.  Each token in the stream is another delay, which cumulatively
may be noticeable.   Maybe a common prefix for the graphic primitives in this
DRAWSEGMENT::Format() would allow you to omit one token.

Suggesting "gr_" or something like it prefixed to the primitive, instead of a full token
"draw ".  My concern is speed later.   However, I'm guessing you are reserving the right
to makes changes later.  :)


I'm guessing it really gets important on the more common objects like tracks and vias,
*especially tracks*, which end up being about the most common object in the file.


ALSO:
==========

Maybe we can get the (track...) on one line as a default, this will help also, since we're using two lines now.

Whitespace in this format is not supposed to matter, but again, I am trying to get out of the way regarding parsing speed later.