kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Seth,

On 7/10/19 2:20 PM, Seth Hillbrand wrote:
> On 2019-07-10 14:08, Brian wrote:
>> On 7/10/19 2:02 PM, Seth Hillbrand wrote:
>>> Start-center-end is under constrained and requires the additional
>>> knowledge of which direction the arc is going.
>>
>> On the contrary.  Start-center-end is fully constrained.  Arc
>> direction is implied and unambiguous.
> 
> Ah yes, you are right.  We can assume a CW or CCW direction and swap
> start/end to match.

Are you planning on allowing either direct or fixing it to a single
direction?  I would think the latter would be preferable.

> 
> The only remaining concern would be robustness.  You can create a
> start-center-end combination that is invalid, so we'd need to define a
> governing parameter.
> 
> The start-midpoint-end triplet can also be invalid but only if you
> assume the midpoint is exactly midway.  The three-point conversion I
> listed previously allows the third point to exist anywhere on the arc
> and avoids this issue.  We would use midpoint for convenience when
> writing the file but don't require it when reading.
> 
> Is there a good solution to this issue for the center point idea?

That was my other concern.  The mid point may not round to 1nm.  It
seems to me you are always bound by rounding and resolution limits.  As
long as you can come up with a robust way to prevent an invalid arc
definition that still meets your end point requirements, then I don't
have an issue with this.

> 
> Best-
> Seth
> 


Don't forget, this will impact all import from and export to 3rd party
file formats so it's not going to be a trivial change.

Wayne