Page MenuHome

Change Text Font in Bold, Italic doesn't work
Closed, InvalidPublic

Description

System Information
Operating system: Windows 7
Graphics card: NVIDIA GTX780

Blender Version
Broken: 2.80

Short description of error
When trying to change a text in bold or italic, it doesnt do anything, even loading the font italic and bold manually from folders in good way.

Exact steps for others to reproduce the error
Create a text, load a font, check italic or bold.

Thank you!

Details

Type
Bug

Related Objects

Duplicates Merged Here
T67020: Bold/Italics Bug

Event Timeline

dono dono (dono) renamed this task from Font Bold, Italic doesn't work to Change Font in Bold, Italic doesn't work.
dono dono (dono) renamed this task from Change Font in Bold, Italic doesn't work to Change Text Font in Bold, Italic doesn't work.Jul 13 2019, 3:16 PM

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.

Dalai Felinto (dfelinto) closed this task as Invalid.
Dalai Felinto (dfelinto) claimed this task.

It is working as expected. To have them change the currently selected text in edit mode use the shortcuts (Ctrl+B, Ctrl+I, Ctrl+U).

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).
  1. 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.
  1. 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.

Dalai Felinto (dfelinto) triaged this task as Confirmed, Low priority.

The buttons set the new default "mode" for new typed text. Like it or not that is the current expected behaviour (not a big fan either).
We could remove the buttons from object mode, that would at least make things less misleading.

@William Reynish (billreynish) wants to visit this for 2.81?

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.

This comment was removed by Robert Guetzkow (rjg).

@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.

dono dono (dono) added a comment.EditedJul 13 2019, 6:16 PM

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.

@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.

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).