A aperture macro can have polygons with holes, and/or many polygons.
When combining polygons holes can be created. So ensure the resulting polygon
is fractured before drawing it.
Fixes#11218https://gitlab.com/kicad/code/kicad/issues/11218
To avoid issues with broken Gerber readers use aperture macros with shapes
without rotation when more than one primitive is required.
In many gerber readers, rotation of a set of primitives is broken
(do not follow Gerber requirements)
The use of printf, wxLogDebug, and std::err/std::out causes excessive
debugging output which makes finding specific debugging messages more
difficult than it needs to be.
There is still some debugging output in test code that really needs to
be moved into a unit test.
Add debugging output section to the coding policy regarding debugging
output.
* Split up the thirdparty code into the thirdparty folder (#3637)
* Create a new kimath static library containing all the math functions
This is part of cleaning the build system for #1906.
This is the first step to allowing non-segments in the line chain.
External routines cannot be allowed to change the line chain without
going through the internal routines. To accomplish this, we remove the
Vertex() and Point() access routines and only leave the const versions.
Transformations are given for both points as well as the chain itself.
This corrects an issue with fill segments-per-circle and moves the error
to segmetns calculation down in a number of functions to expose the
single value for approximation
- New GAL draw layers for GerbView
- Improved bounding boxes for Gerber shapes
- Switched to use of SHAPE_POLY_SET for polygons
- Add GAL methods to support selection and rendering
- Add GUI support of editing GAL options
- Rename get/setActiveLayer to Get/SetActiveLayer to match convention
In Gerber files the char 'X' is used as separator.
But when reading parameter values, the sequence "0xnnn" is a number in hexadecimal format, and the 'X' char is not seen as separator by usual strtod or strtol C functions.
This is now fixed.
eeschema now supports arbitrary colors for all object types, and
pcbnew does in GAL canvas. When switching from GAL to legacy canvas,
pcbnew will convert colors to the nearest legacy color.
The plan goes like this:
- eeschema still uses int in decidegrees
- all the other things internally use double in decidegrees (or radians
in temporaries)
- in pcbnew UI the unit is *still* int in decidegrees
The idea is to have better precision everywhere while keeping the user with int i
angles. Hopefully, if a fractional angle doesn't come in from the outside, everything
should *look* like an integer angle (unless I forgot something and it broke)
When the time comes, simply updating the UI for allowing doubles from the user should
be enough to get arbitrary angles in pcbnew.
- Removed spurious int casts (these are truncated anyway and will break
doubles)
- Applied the Distance, GetLineLength, EuclideanNorm, DEG2RAD, RAD2DEG
ArcTangente and NORMALIZE* functions where possible
- ArcTangente now returns double and handles the 0,0 case like atan2, so
it's no longer necessary to check for it before calling
- Small functions in trigo moved as inline
jean-pierre charras
Marek Roszko
Jeff Young
Wayne Stambaugh
luz paz
Ian McInerney
Seth Hillbrand
Seth Hillbrand
Jon Evans
unknown
Maciej Suminski
Lorenzo Marcantonio