LEFT Justified text when edited takes the RIGHT anchor point as the fixed orientation point.
RIGHT justified text also takes the RIGHT anchor point as the fixed orientation point.
Shouldn’t justified text, when edited, be fixed on the justification side?
As you can see, editing a left-justified text block such as in an architectural notation symbol throws the formating off necessitating a time-consuming edit to adjust the text block back to proper alignment.
Similar consistency issue with top and bottom justification. The UI for all other applications that allow text block editing (that I am familiar with), the top aligned bars indicate TOP JUSTIFICATION with the anchor point on the top, the bottom aligned bars indicate BOTTOM JUSTIFICATION with the anchor point on the bottom. So a change in text height orients to the fixed justification point. Rhino UI in this regard is the opposite. As I am used to working with InDesign, Word, Excell, etc. the Rhino UI seems counterintuitive.
Hi, I was able to replicate your example by inputting new text.
However, I usually copy existing text that is similar to what I need and edit it. It must be getting corrupted? I attached an example file if that is of any use. Thanks for looking into it!
Hello- thanks, I see this on editing as well. Hm - that is, I can see it editing the text in your file, not, so far, with new text. - has yours been mirrored at any point in its life?
Pretty good chance it has been but I can’t say for sure. Copy and edit is the predominant method for creating new text so over the life of a piece of text it goes through all kinds of manipulations.
Hi Pascal, following up on this corrupted-text-block issue.
Is there a way to reset a text box entity so that it performs normally again?
Is this just my problem or is there possibly an obscure issue with the way text boxes are coded enabling them to take on conflicting orientation characteristics?
I suppose that depends a bit on the definition of “normal”.
All of the text objects in your files have style overrides. If you remove those overrides, all objects will behave “as designed”. That means that everything will be top-left aligned.
I did a bit of searching and (1) it’s not just your problem, and (2) the behavior is by design.
I’ve added this thread to item RH-42519 and also linked that up with RH-61044.
For the time being, for this to work as you expect, you’ll need to create different annotation styles for top-left, bottom-left, top-right, and bottom-right.
-wim
Thanks for your explanation . It and something Pascal mentioned earlier indirectly inspired an understanding of the problem I am having.
Mirrored text responds in the opposite manner to what you would expect. And there is no visual indication that text has been mirrored.
In the attached image all text shown is oriented Left Top but mirrored vertically and horizontally. So a text block which is LEFT TOP oriented with no overrides when mirrored maintains the same orientation indications in the text settings menu (Left Top) while visually showing anchor points that are, depending on how it was mirrored, Right Top, Left Bottom, and Right Bottom. In addition the Left Top text when edited responds like it would if it were Right Top, Left Bottom, and Right Bottom.
Knowing now how this works I can manage it.
One of three things would solve this issue
Provide and indication that text has been mirrored
Adjust the orientation characteristics in the text settings menu on execution of a mirror event so that mirroring a Top Left orientated text block on the vertical plane changes it to Top Right etc.
When mirroring do not allow orientation anchor points to change.
Similar text manipulations of text blocks are handled in programs like InDesign with good intuitive logic which is a good reference for how this situation might be improved.
I am adding this related MIRROR-TEXT issue which has always confused me but exploring the issue in this post I now get what’s happening. But I think it should also be forwarded to the feature request thread for comment.
The drag-point which allows resizing of the text box has two issues in my opinion:
you should not be able to drag the box beyond the justification side of the box causing the box to, in effect, mirror. The justification side is a fixed location and the rag of the text is what should change on dragging.
Because mirroring text creates a conflicting justification indication, adjusting tex-box-width by dragging must be done by dragging the justification side which is counter-intuitive. Again, the justification side is fixed so you should not be allowed to drag the justification side.
If you need to adjust the justification side you are moving the text so a move function is more appropriate.
Also the 4-year-old request RH-42519 you reference above to maintain text box position when changing justificaiton. I can’t comment on the YT_ forum but I must agree with Brian G, This is how most text applications work and how intuitively I would expect the text to behave during this setting change process. This design change would be a good imporvement.
