This is a little tricky, but this seems to be the simplest
way to approximate the right text placement.
There are still some minor offsets and text size adjustments,
which might be possible to compensate for by experimentation.
I'm not exactly sure where the flip comes in, but it seems to be
universal at least across various files:
* RK3588
* BeagleBone Black
* Some local boards as well
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/19224
All the footprints have a ref-des field by default in KiCad, but if the
silkscreen text isn't present in the imported file, we should hide it.
If we see a silkscreen refdes, _then_ show it.
These seem like footprint fields, but there is no obvious way
to associate them. Dumping them on the the silk/fab layers creates
huge overlapping spam on the board, so for now, just leave them
out.
Allegro has a more "2D" layer system with classes (e.g. DEVICE TYPE)
and subclasses (SILKSCREEN_TOP), which make things difficult to
make map cleanly to KiCad layers.
Some texts were left out of the GRAPHIC_ITEM -> BOARD_ITEM
dispatch in some paths. Unify this item creation to avoid
this possibility (and reduce duplication).
This seems to be a lossy export conversion - it's not possible
to tell apart a closed zone and a line that happens to end where
it started.
Look for features that indicate that a sequence of graphics are
"open" and should be rendered as a set of discrete graphics,
or "closed" and should be a single polygon.
At least for objects in the BeagleBone Black export, this seems
to work well.
This is a bit of a hack as it will still only allow
9 more layers and drop the rest, but it's a start and
allows testing using the Beaglebone Black board and the
board in issue 19174.
Some circles are represented as ARC with start == end, but there
are also CIRCLE elements.
For consistency with the existing code, actually use 360-degree
arcs for circles (which also allows them to be used in polygon
holes if needed)
These appear to be 'unplaced' components, which we don't really
have a good way to represent at the moment. For the time being,
skip them.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/19174
By adding points to holes as we go, we leave ourselves open
to adding invalid (<3 point) holes to the polygons. This causes
crashes if it happens, so we should never allow it to happen.
Instead of building holes in-place, construct them externally
and only add them if they are valid.
This probably wouldn't actually happen for a valid Fabmaster
file, but if it did, it would be bad new, and we shouldn't leave
crashable pathways facing user input.
Polygon segment dragging no longer pays attention to the
H/V/45 global setting, and now always enforces a drag normal
to the original segment. Polygon vertex editing no longer
enforces a H/V/45 constraint, instead relying on the grid and
object snap.
jean-pierre charras
JamesJCode
Dhineshkumar S
Jeff Young
Alex Shvartzkop
Jon Evans
Seth Hillbrand
John Beard