On 2017-06-27 06:18 PM, hauptmech wrote:
I suspect it will come up about as often as it has (so once in 5 years?).
Perhaps you could a couple lines of documentation for fp_arc in the file
formats pdf so the next person that encounters this has a chance to
recognize the error?
It was
or use boost::variant and switch to std::variant in the future?
On 28 June 2017 at 00:18, hauptmech wrote:
> The tokens for circles are fine.
>
> I suspect it will come up about as often as it has (so once in 5 years?).
>
> Perhaps you could a couple lines of documentation
The tokens for circles are fine.
I suspect it will come up about as often as it has (so once in 5 years?).
Perhaps you could a couple lines of documentation for fp_arc in the file
formats pdf so the next person that encounters this has a chance to
recognize the error? It would have saved me a
The tokens in the file format match the member names of the DRAWSEGMENT
object so I see how this could be confusing for arcs and circles.
Changing the "start" token to "center" is not a can of worms that I want
to open.
On 6/27/2017 8:45 AM, hauptmech wrote:
> Just to clarify, I'm talking about
Just to clarify, I'm talking about the file format not the internal
implementation.
The file_formats documentation has the old format using 'center' and
'start' for circles and 'start' and 'end' for arcs (which go from a
start point to and end point as the terminology suggests). All good and
It's not an error. Arcs are part of the DRAWSEGMENT object which
encapsulates line segments, arcs, etc. The start coordinate (m_start
member) is the center point for arcs and circles. It is documented as
such in the KiCad source.
wxPoint m_Start; ///< Line start point or Circle and
In the module s-expressions, what is the rationale for having arc center
labeled 'start' and having the arc starting point labeled 'end'?
This bit me as I was writing an Allegro footprint extractor to kicad and
got confused why my start,end,angle arcs were not displaying correctly.
Assuming
7 matches
Mail list logo