The previous commit merged pads with copper areas. This was appealing
but broke when the pad and the area were meant to have different
size/shape technical layers. Small pads = Small paste. Instead, we do
not merge the pads but we assign them to have the appropriate nets in
KiCad, allowing the same effective result but keeping the technical
layers correct
(cherry picked from commit 51eb7aa5b5)
In Altium, copper polys will be connected automatically to their
associated pads. In KiCad, we need to do the equivalent when parsing,
which is to combine the joining copper into the underlying pad. We also
don't want to treat copper polys as proxy pads without the original
anymore.
(cherry picked from commit 7102d9f72a)
Also, corrects a minor issue with the text width calculation where
Altium calculates centerline to centerline but KiCad text heights are to
the edge of the stroke font. Need to still do better adjustments for
the various altium stroke fonts
Fixes https://gitlab.com/kicad/code/kicad/-/issues/9468
(cherry picked from commit 7e561acf53)
When loading schematics/pcbs, notification of font replacements might be
warranted but in libraries, this warning is not helpful and intrusive
(cherry picked from commit 11c6164934)
This removed the hatch fill import functionality,
and is no longer needed now that the root cause was found.
This reverts commit 616510aca2.
(cherry picked from commit 80b7f5fcbf)
- Filled zones using the hatch pattern cannot use the primitives from Altium.
the filled shapes must be rebuilt.
_ Filled zones using the hatch pattern with a very small gap are now converted
to a polygon pattern. Otherwise the calculation time can be very big.
From master branch.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18156
This appears to happen in some very old (Protel 3.0.0?)
library files.
The example given in issue #16514 always has 0 in the last 4 bytes.
It's not clear exactly what these bytes do, if anything, so
just skip them and assume the holerotation is 0. If it's not 0,
error out - at that point it might be possible to determine what
the value means.
This appears to correctly import the file provided in the issue.
As the license on that file is unclear, we probably can't just
add it as a unit test and it's rather tricky to special up a
binary file test-case for it.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/16514
An importer should not stop import when an item just looks strange. Just skip it.
It can happen with old files.
Better do not import one item than import nothing.