The way it currently works is awkward. You can set the properties before typing and it will appear as you'd expect. However the interface doesn't allow to change the format with these buttons once typed as far as I'm aware. This is not a regression though, the behavior was already like this in 2.79b. The underlying features are there, but the operator behind the buttons isn't context sensitive (e.g. change all letters when in object mode, change selected letters when in edit mode). You can change individual letter by setting them through bpy.data.objects["Text"].data.body_format[0].use_italic = True, where "Text" is the name of the object and the index in body_format[0] is the character you want to change. See the API docs for more formatting options.

@Campbell Barton (campbellbarton) @Pablo Vazquez (pablovazquez) am I correct with this assessment?

Hello Robert, thanks for answer! I understand and I was not necessarely reporting a regression since it is indeed behaving like this already in 2.79. But my guess is that anyone will expect the bold/italic button to work like in any basic text-tool out there. It is taken for granted that we can change any letter from bold to non bold by selecting them and pressing the bold button if such button is shown in the interface. A different behavior will lead to people thinking it is a bug (like myself and other people I asked). If it is a limitation that you can't necessarely fix due to time constraints or complexity, I would suggest updating the interface/tooltip to let the user know what the button does for real. Thank you!

@Dalai Felinto (dfelinto) : I can only agree with dono. If you humbly believe those buttons are working as expected, I encourage you to take a step back and think twice about what a bold button in a text-editor should do.

1. Blender 2.8 imho is all about accessibility,, interface and stopping using and abusing shortcuts. The only way to know the Ctrl+B short-cut for new user is, I believe, within the Font menu. It is not displayed in the little status-bar the very bottom where shortcut are now shown nor anywhere else (I think).

2. The font menu is not really an obvious place to look for when all the text relevant settings are found in the text object properties in the first place. PLUS, I'm editing the text rather than the font, so to me the name is not appropriate.

3. Ctrl+B in any text-editor IS the shortcut for the bold button already. It is not an extra operator that does not behave like the bold button does. Clicking the bold button and Ctrl+B SHOULD lead to the same operation. It is assumed that the bold button will turn any new character to bold AND selected characters to bold.

I understand if it's not trivial to fix, but if it should remain like this I encourage you to rethink the way it is displayed in the interface. Thank you for your time and congratz on RC1 release!

Hello Dalai. Thanks for answer. I don't think it is working as expected. When you click on the buttons italic/bold, it doesn't work at all. When you have buttons in UI, what is expected is that the buttons do something when you click on it. May be better is to not put in UI these buttons? Thank you , all the best.

What I'm trying to say is, this is a design issue, not a bug per-se. We are open for patches and design proposals, but just pointing to a (known) weak design doesn't fit in with the other bug reports (it is no one's fault really, it is often hard to tell when something is a bug or not). That said I appreciate the attention by @dono dono (dono) on trying to spot these issues in Blender.

@Dalai Felinto (dfelinto) I agree this is not a bug, but imho bad UX. Seems like something minor that could be done for 2.81 and added to the UI paper cuts.

Thank you Dalai and Robert. Indeed it is difficult for me to know if it is a bug or not. Thanks to you and all the devs for this amazing 2.8 and all your fantastic work on it! All the best from France.

Indeed it's hard to tell between a bug or a limitation sometines, and where to report it if report it at all. It looked like those small confusing interface things that you guys have been tackling all over the place for months for the 2.8 so I figured I'd give my two cents on it.
Anyway, Roger that, thanks for your time, appreciate it.

In T66861#720734, @Robert Guetzkow (rjg) wrote:

@Dalai Felinto (dfelinto) I agree this is not a bug, but imho bad UX. Seems like something minor that could be done for 2.81 and added to the UI paper cuts.

Agree that UX is the issue we are facing here. But just to illustrate how things are not so trivial to solve sometimes.
What we have now are "checkboxes". They are supposed to reflect the property value of something (an object, a character, the default mode for new text, ...).

Now let's say we were to change from current behaviour (the default mode for new text) to e.g., the mode of the selected text. Now what if the selected chars have each a different style value (half bold, half italic) what do we show in the UI?

Anyways I'm not saying there is no solution, I'm just always wary of jumping to quick solutions without stepping down a bit and looking at the problems from multiple angles.

In T66861#720735, @dono dono (dono) wrote:

Thank you Dalai and Robert. Indeed it is difficult for me to know if it is a bug or not. Thanks to you and all the devs for this amazing 2.8 and all your fantastic work on it! All the best from France.

No problems, it is difficult for us sometimes as well. And thank you for your kind words.

Now let's say we were to change from current behaviour (the default mode for new text) to e.g., the mode of the selected text. Now what if the selected chars have each a different style value (half bold, half italic) what do we show in the UI?

I'd say mark everything that applies to the text, so in your example with mixed styles it would result in having both bold and italic enabled. Disabling it changes it for the whole selection. It's certainly something that needs to be discussed beforehand. Given that text editors have been around for a while, we should have plenty references on how other software has implemented this.

Just to be sure, what dono and I, I think, are suggesting is that the bold button should still set the default mode for new text but also for the selected text if any text selected (although I'm not sure making the button contextualized is doable).

This indeed rise the issue you mentionned but I'd suggest simply mimicking behavior like in Libre-Office/Google Docs and I believe most others text-editors if it is doable.

Selecting multiple chars while some are bold and some are italic will not update the bold nor italic icons status since you can't really solve this in binary. If they were displayed like "on" or "off" before, they'll stay the same, althouh I believe we could hint that we have multiple values in the selected strings like displaying the text in the "bold" or "italic" button in italic or with a little star in the end or something. I believe anyway that this issue would be drastically less confusing (since it is already the expected behavior from most text-editor) than having the bold/italic buttons stick to their current behavior.

And then clicking the bold/italic button on a string with different style value all toggle the remaining non-bold/italic characters to bold/italic.

@Dalai Felinto (dfelinto): We should most certainly make improvements to this area. Pressing Bold, Italic, Underlined toggles should affect the selected text, just like any text editing app would. We should make this work as expected.

An issue here is that the most prominent place where these settings are shown is the least useful.
The "Font" menu has the ability to adjust these settings too.

We could make it work on the selection without large changes:

• The buttons indicate the current state where the cursor is located.
• Pressing them toggles the state of the entire selection (like the menu items currently do).

To work more like most word processors (which show when the state is mixed), could be cached on evaluation (eg, when drawing the selection).

Initially I wanted to write a bugreport, but before I found this "bugreport" from July (!). And I wonder, that this is closed and the behavior hasn't changed.

I just want to mention, that during the blender conference I ask 10 skilled blender pro user to paste a sentence in the text tool and make a single word in the middle of it bold.

No one was able to to it.

And when I showed, how to to it... it was funny. @Julian Eisel (Severin) was smart and opened the online documentation, read about how it works, and then "solved" it. But I think this task should be reopened and these button should at least for marked text as operator or even better: a multiline textbox to paste in text and using tags for formatting. And the bold button adding these tags for marked text. Like: "Make the [b]Text in Blender[/b] great again."

This bug absolutely should be reopened. I found the current behaviour both unexpected and unworkable.

I want to create a text object with the text "Markku Kivimäki" in Small Caps. I can't type the text after switching to Small Caps, because there is no way to add a special character for "ä". I can't paste the text, because it ignores the Small Caps mode.

The only workaround I found was to set the mode to Small Caps, then in the Python console put:

bpy.ops.font.text_insert(text="Markku Kivimäki")

@Joel Holdsworth (jhol) I don't believe Small Caps work the same way as bold/italic. Better to have a separate report for this (and refer back to this one).