Currently leader text is located next to the leader line end.
This is bad orientation and not according to the standards and best practices. Can it be placed above the line somehow? Can I change the default behavior?
, now I understand why @Dani_Abalde uses a term “McNeel Language”
Underlined is a text feature, not annotation feature, for crying out loud!
Also, when you set the position of the text as Bottom
It should mean the text is below the line.
Respectively: Top Means above the line and not below it!
Your logic is terrible!
This is the same as Text Justification vs Text Alignment absurd.
@ivelin.peychev wim helped you and you thanked it with more complaints. today is fullmoon i guess many are getting kind of crazy.
also i assume that the positioning is meant for the leader instead of the text.
No, it’s the position of the text relative to its insertion point.
ok, that is confusing…
see!
also,
Wim is McNeel now, he’ll have to (learn to) take the bitter spoon for the confusion in the software.
Why? The text position has to be relative to something. This is CAD, not an illustration or page layout program, and everything in Rhino has control points which tell the program where objects are and allows one to keep track of and manipulate them.
Because is not the standard behavior. We are talking about annotation, and we are used to think that documentation belong to layout and paper orientation. At least this is how I see it.
Even in layout space, Rhino objects have control points…
Yes, I know… I still find it confusing, but let’s leave it like this 
many might not even do any constructional drawings. while the number of these might be sparse, we are still talking about text. when something is called “Leader Text Position” there is no indication of it to be aimed at the insertion control point. not even after using it for years would that have ever crossed my mind. so yes it is unconventional and confusing.
communication does not have to transmit personal frustration. if you try to frustrate others all you get is more frustration. wim did not earn that extra salt, a bit pepper maybe but thats it 
I say this because every complex system has its vocabulary, not for any other reason. Different people can call the same thing differently, and for efficiency it is convenient to use the same words. And the same word can mean different things to different people. It’s a relative thing that depends on the context, as everyone knows.
It seems simpler than it really is to maintain a consistent vocabulary over the years and with intertwined use cases and several people developing, because the complexity of the reality that one is trying to describe is many orders of magnitude greater than the complexity of the capacity to describe in human language, and if one does not standardize a nomenclature or a taxonomy, these unimportant problems are sure to come up.
I was talking about text (block) positioning in general, not just leaders. They both use the same naming convention - it would be really confusing if leader text position naming was different from regular text. The leader text insertion point is just the end of the leader.
In the end this is all word play. It doesn’t really matter what you call it, as long as you know what term corresponds with what action. Although there might be some general conventions, there is by no means accordance between all the different software packages as to which term corresponds with which action. (we had this discussion previously over the term “justified”).
i would say it is important that it is intuitively understandable. if there is a broader justification which one might not perceive as such then it is probably not a good method.
Yeah, but what does intuitively mean? It depends on your frame of reference.
Is your frame of reference the text block itself, or the insertion point?
i have to check that video later looks interesting, but i assume its not crucial for the discussion now.
when a stone falls to the ground which probably is true in switzerland nearly the same way as it is true in austria or urugway, then this experience may result in intuitively understanding where the next stone may fall to.
and besides all that groundbreaking wisdom, i see absolutely no reference (on mac V6) other than towards the text itself which is hell of a confusing.
and having to choose underlined for the text to be above the line is also very weird.
Bottom puts the text ON the 'baseline" (i.e. the bottom of the text is aligned on the baseline) but does not extend the leader under the text.
Underlined moves the text slightly above the baseline and simply extends the leader to go under the text. The text is moved upward to keep it from touching the leader line.
I’m sorry I have to give examples from another software but when you’re using non-standardise naming conventions at least the UI should be unambiguous:
Rhino needs to keep up.
That’s why there is probably a lead in the dev company that makes the decision to keep or change a certain word/term/numenclature and not leave all these decisions to the programmers.
The problem with Rhino is not that they are not consistent with these names regarding being the same in all releases, the problem is that they are not consistent with the accepted numenclature and naming conventions in the industries. All engineering disciplines try to be consistent in this and Civil Engineers could understand drawings of Naval Architects or Mechanical Engineers, even Architects because of this consistency. Same have to happen with software these engineers use, and Rhino kinda doesn’t follow this.
This is as “unimportant” as the UI Overhaul discussion! In fact it is part of it.