Eeschema arcs do not render properly

[abetusk]

See abetusk@ffd269d for a fix. I think an older version of Kicad didn't use the 'startX startY endX endY' trailing portion for the Eeschema "A" (arc) command and used the start and end angle only. These angles are almost redundant when considering the start and end points. Instead of settling on a convention of always one direction (ccw or cw), Kicad uses the angles to determine if it should render the arc ccw or cw depending on whether the start angle is bigger or smaller than the end angle (after some renormalization).

The comments in the above link have more detail. I use a crude solution of just stuffing in numbers into the start and end angle, but considering how their actual values should be ignored anyway, I feel that's a better solution than stuffing in semi-sensical numbers for the angles and potentially confusing a future developer trying to reverse engineer the byzintine eeschema syntax.

The relevant KiCad source logic can be found in the "TRANSFORM::MapAngles" method in "eeschema/transform.cpp".

To see an example of mis-rendering, check any of the "OSHW-LOGOL_OSH2-LOGO-S", "OSHW-LOGOL_OSH2-LOGO-M" or "OSHW-LOGOL_OSH2-LOGO-L" in https://github.com/sparkfun/SparkFun-Eagle-Libraries/blob/master/SparkFun-Aesthetics.lbr .

I'm happy to issue a pull request but I want #26 resolved before I do.

[DanChianucci]

Hey, I closed out #26. I believe the new .gitattributes file will prevent this from happening again (all text files should be converted to unix upon commit).

Looking at the fix you have provided I am weary as to how this will affect arcs within pcbnew footprints. The getWireInfo function is used in both eeschema and pcbnew conversions. Unless you know that pcbnew perform the same way I would rather the fix be implemented in the symRep function which only affects the eeschema conversion.

Other than that it looks good.