Another peculiar scripting issue:
When getting the corners of the bounding boxes for pads and text, it’s a little strange. I’m not sure this is definitive, but seems to work for my layout. I haven’t specifically tried all different combinations of rotated module (footprint) and rotated text.
This procedure works for free text (i.e. at the top level) and for text/pads within modules. The idea here is to get a bounding box (which is always reported at orientation 0) and to get a rotation to apply to the bounding box. Applying the rotation to the bounding box gets the final region on the board.
Pad (only orthogonal tested): always take the bounding box. It is oriented correctly regardless of footprint orientation. That is, rotation applied is zero.
I would expect that a non-orthogonal rotation applied to either pad or footprint would require different code.
bounding_box = textobject.GetTextBox()
textobject.GetOrientation() + textobject.GetParent().GetOrientation()
If the textobject is free text (i.e. it’s at the top level instead of in a footprint), the parent will not have a GetOrientation attribute. Here’s the code:
parentorientation = m.GetOrientation()
parentorientation = 0.0
orientation = object.GetOrientation()
And the GetCornersRotatedRect function:
# rect is entered as a KiCAD boundingbox in a wxRect format (indexable)
# rect format is (upper left x, upper left y, width, height)
# orientation for this algorithm is -(kicad orientation).
# This is because algorithm orientation is in the opposite direction
# of kicad orientation.
# (note that orientation is returned as tenths of a degree,
# so this also converts to floating point degrees)
orientation = -orientation/10.0
# the center is the rotation point
ox,oy = center
rpoints = 
for px,py in (
# rotate point around center
pox = px-ox
poy = py-oy
nx = cos * (pox) - sin * (poy) + ox
ny = sin * (pox) + cos * (poy) + oy
# add the start point to form a closed polygon