QuickSilk - add ability to rotate part while retaining relative silkscreen position

[RnDMonkey]

It would be useful to be able to rotate a part while retaining the relative position of its Designator and Comment silkscreen texts, but how should it be implemented?

[RnDMonkey]

Initial thoughts:
If QuickSilk was used to place the text initially, then the autoposition location can be inferred from the text's current justification setting (Solution 1). That's the easy case.

But what if the text was not placed with QuickSilk so its position rules can't be reliably inferred?

• (Solution 2) Should its current anchor be used to determine the autoposition location?
• (Solution 3) Should it try all nearby/likely autopositions and see which one ends up closest to the original placement?
• (Solution 4) Should it just counter-rotate the text around the rotated part then move it toward/away from the part until it has a valid placement?

[RnDMonkey]

Solution 1:

• Pros:
  • Easy and likely to give good outcomes
• Cons:
  • Relies on text justification to infer placement if the tool is to be single-click (otherwise you would want a two-step process where you rotate the part then pick the new autoposition - too cumbersome)

Solution 2:

• Pros:
  • If anchor was set by QuickSilk or by the same criteria of growing away from the part, this is easy
• Cons:
  • If anchor does not make sense for that position, results will be very different than expected

Solution 3:

• Pros:
  • For square-ish part outlines, results should be very satisfactory
  • Doesn't care much about original placement method of text and "refreshes" it
• Cons:
  • Lower performance having to try multiple positions
  • For parts with a large aspect ratio of their bounding box, the closest position of side-aligned text may be center-aligned or vice versa

Solution 4:

• Pros:
  • relatively intuitive
  • good performance
• Cons:
  • For parts with a large aspect ratio of their bounding box, side-aligned short text could end up appearing center-aligned, or could end up far offset to the side

[dsicon]

If I understand I think I like #1 best.
What if I had manually placed (I am a little confused about the autoposition property in this context) and then rotate the part, usually resistors or caps I would want the designator to stay where it was and not travel with the part.
Would #1 work like that?

[RnDMonkey]

@dsicon the way it would work with #1 is if you use QuickSilk to, say, place the silkscreen text in the "Left-Below" octant around the part, the positioned text would be aligned to the Top-Left corner so that the text grows down and to the right. If I were to come along and rotate the part, I would note that the text alignment is Top-Left and infer that the user placed the text in the "Left-Below" octant. Then I would do the rotation on the part and re-apply the QuickSilk routine as if the user clicked "Left-Below" octant again. One of the right-two options below, depending on what we agree is better. I prefer the "ALT" case.

[RnDMonkey]

I think the results in the rightmost column below make the most sense:

[RnDMonkey]

@dsicon the "autoposition" property in this context is how Altium's internal algorithm places the designator around the part. The key interaction between this and what QuickSilk does (and how I would infer what autoposition was originally used) is that QuickSilk sets the text's justification anchor so that the text always grows away from the part. If you had a manually-placed designator that didn't have the expected justification, it could mistake what side the text is on, sort of.

I can probably come up with a more agnostic way to determine what the closest autoposition location is, I just need to be careful about performance and corner cases. For example, I could counter-rotate the text, see what "side" of the part its center mass is closest to, and try autopositions from there. A little bit of solutions 3 and 4.