I noticed that selecting fonts using the TextObject command does not work consistently. I can choose a variety of fonts but the results are always the same. I’ll see if I can attach a video below:
Eventually I can get it to “snap out of it” and actually change the font, but obviously it should work the first time.
The reason the font is not changing is that when the cursor is at the end of the text changing the font, bold, italics, or underline only changes for what you’ll type next. If the cursor is anywhere but at the end then the whole string will change when you change the font. There was a request for this: https://mcneel.myjetbrains.com/youtrack/issue/RH-41051
I can see that it is confusing so we can discuss further.
Now that I know I need to highlight it first, I should be okay. I mainly control the font through scripts, and that works well, so don’t revisit this on my account. If others have problems here I will know how to direct them.
Almost, except that if the text control has focus and the cursor is anywhere but at the end then changing the font, bold, italics, or underline applies to the whole string. This was requested because enough users were annoyed at having to select the whole string to change it’s format.
Just because a few users have requested non-standard behavior, do we want to add the extra confusion, training, support, and documentation load on everyone else?
i hope not, if how it works now enables one to use several fonts in one line, then rather keep it so and highlight the text first to change the font. sorry didnt use v6 just a mac user but this what i see makes sense to me and hope to have it on mac the same way.
honestly i would anyway go for editing the text directly in the viewport and having only the font selection where it is.
I’m not sure that what’s standard for text editors is what is expected for annotations. In Dan’s screencast above the controls are working just like a text editor, i.e., the font doesn’t change because nothing is selected but he’s expecting it to change.
This is how the feature evolved:
it used to work more like a text editor, i.e., if no text was selected then no text would change when you changed a font property but text you typed from that location would take on the new properties. You had to swipe select first to make a change.
users were confused by that because in Rhino 5 the whole string changes even if nothing is selected so we (@brian, @lowell, a few users, and I) decided that if no text is selected the whole string should change.
later @John_Brock and @lowell asked for an exception to the above rule: if nothing is selected the whole string changes except when the caret is at the end of the text string (RH-41051).
In hindsight my opinion is that we should remove the last exception and the whole string should change even if the caret is at the end. I’m not sure if the problem: "if I have some normal text and I now want to type some bold text, I can't. I have to type the text and then change it to bold."
that is described in RH-41051 is a big concern once you get used to the 2 simple rules:
if nothing is selected, the whole string changes,
swipe select to change a substring
To me that’s what seems to be the least confusing and is the best compromise. Of course let me know your ideas if you think I’m wrong.
This all still seems very odd. What happens if you plan to add some bold at the end and there is already some bold and some not? Or, nothing is selected with some bold and some not and you click bold… what is expected to happen?
I still think it should work like Google Docs and Word. Otherwise, we are going to spend the rest of our lives in this discussion. Plus adding extra words to the Help that nobody reads. Spending extra time in class. And confusing new users.
You’d type the new content, swipe select it, and click bold
nothing happens if the caret is at the end of the text or the complete string turns bold if the caret is anywhere else.
We had many discussions and this was the consensus. Maybe I don’t find it odd because I’m used to seeing it but I do believe this is not a bad compromise (maybe except for the last of the 3 points above.) but I can change it.
If our goal is to have the TextObject, Text, and Leader editing work like a word processor, then about the only thing that is working correctly is the behavior that started this thread that was described as a bug!
Here’s how Google Docs works with a new document:
And here’s how Rhino works with a new TextObject:
That said, almost everything people do with Text and TextObject are small pieces of text, and the way Rhino behaves may actually be more useful than making it work exactly like a word processor.
@brian,
In your screencast after changing the font you state that in your judgement Rhino incorrectly changes the whole string. I guess it’s been a while but you logged the request for it.
Also, in your screencast everything behaves like I described above although there’s one little glitch that makes it confusing: when clicking on the bold, italic, or underline buttons the text box never looses focus so the caret stays where it is as expected but when changing the font the text box looses focus so you have to click in the box again to give it focus. We’re discussing fixing that here but there appears to be a bug in setting the Focus back to the RichTextArea control and Curtis is looking into that.
Hi @Alain what I meant when I said “incorrectly changes the string” I meant when compared to Google Docs. My final comment in the post is
almost everything people do with Text and TextObject are small pieces of text, and the way Rhino behaves may actually be more useful than making it work exactly like a word processor.
So, I guess what I don’t fully agree with @bobmcneel’s view that
…it should work like Google Docs and Word. Otherwise, we are going to spend the rest of our lives in this discussion.
All that is to say, I don’t think I have the right answer.
My mistake. I used a font which doesn’t come with a font-family. Whereas in the text editor the text appeared bold, it didn’t work in the model/layout area.