The fractional part of Altium schematic units is an integer number of
1/10000 mil segments, which is 2.54 nm. The internal unit of eeschema
is 10 nm, so each fractional unit in Altium is 0.254 base eeschema
units. To be consistent with
cf33cfcad1
we round to the nearest 10nm for each element
Fixes https://gitlab.com/kicad/code/kicad/issues/11742
(cherry picked from commit 6fef054c51)
We now test the midpoint (B) of the 3 consecutive polyline points (A, B, C), since (assuming the angle between AB and BC is > 90 degrees) AC is always longer than
AB or BC. This minimizes the distance computation rounding error (in the previous algorithm, taking the point C for colineraity test) if AB is short and BC is very long, the test would
often fail due to rouding error in projection/line distance computation
(cherry picked from commit 3aed13278d)
Guarantees 1 LSB error, while the C++ double type has 55 mantissa bits (meaning for sqrt(X) >~ 2^22.5) the error is not guaranteed.
(cherry picked from commit e6ebc2b9b9)
We can't know that all holes will be ccw when entering unfracture.
Instead, we set the largest polyline to be the outline and the others to
be the holes.
Mainly CacheTriangulation() was creating triangles using partition mode.
But this mode is optimized for Pcbnew and Gerbview and different internal units.
Now CacheTriangulation() is used in no partition, much faster in GERBVIEW_PAINTER.
From Master branch
Inflate with linked holes needs to account for fractured polygons,
otherwise inflating with positive value will create rounded divots where
overlapping fracture lines meet and inflating with negative value will
create spaces between fracture lines.
Calling Simplify before Inflate takes an inordinate amount of time as
the Clipper healing routine is rather slow. Our own Unfracture is meant
to heal the results of our Fracture routine and works much more quickly.
After healing, we still call the Simplify routine
Clipper can handle complex input polygons but we will sometimes struggle
dealing with outputs from the inflate routine that have degenerate or
overlapping points. Calling Simplify after the inflate keeps our
polygons easier to handle
Fixes https://gitlab.com/kicad/code/kicad/issues/11036
Since we use center points to move back and forth for angle and
adjustments, we want to ensure that our center point is stable.
Rounding using integers introduces a 0.5 int uncertainty in each
measurement. These are combined together multiple times to calculate
the center point, which combines the uncertainty. Propagating the
uncertainty to the final calculation allows us to assign a range of true
values and pick the value that is most likely the correct value.
Fixes https://gitlab.com/kicad/code/kicad/issues/10739
(cherry picked from commit ed7222b1e7)
*Fixes in the SVG import polygon postprocessing:
- don't drop subsequent polys when a non-filled primitive is imported 'in between'
- fix missing holes (also related to the interleaving of stroke and filled shapes, depending on the software that wrote the SVG file)
*GRAPHICS_IMPORTER_BUFFER: forgot to store the indices of the paths belonging to a compound shape
*pcbnew: GRAPHICS_IMPORTER can now recognize multi-path shapes (and postprocess polygons with holes into Kicad-compatible fractured polysets)
*SHAPE_POLY_SET: polysets can now be built from a bunch of arbitraily ordered oriented outlines.
Used by the SVG hole support
*SVG_IMPORT_PLUGIN: enable postprocessing of polygons with degeneracy and holes
*pcbnew: SVG importer support for even-odd fill rule
Handles checking output of the arc to ensure we don't end up generating
an invalid arc. Also keeps the limit of the arc angle to be (360,360)
excluding 0.
Fixes https://gitlab.com/kicad/code/kicad/issues/10070
The arc2segment collision should at also include the arc endpoint projections on the segment being tested. Not sure it covers all possible cases, though.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/9023
Clipper might mess up the rotation of the indices such that an arc can be split between
the end point and wrap around to the start point. Detect if this happened and fix it as
required.
Also, handle arcs at the last segment of the chain correctly, meaning we can have arcs
towards the end of the chain that finish at the starting point of the chain.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/9670
Alex
Seth Hillbrand
Tomasz Wlostowski
jean-pierre charras
Jeff Young
Marek Roszko
Wayne Stambaugh
Roberto Fernandez Bautista
Jon Evans
Johannes Pfister