Change Text Font in Bold, Italic doesn't work #66861

Closed
opened 2019-07-13 15:04:29 +02:00 by dono dono · 33 comments

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!Font_bug.JPG

**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!![Font_bug.JPG](https://archive.blender.org/developer/F7605518/Font_bug.JPG)

#67020 was marked as duplicate of this issue

#67020 was marked as duplicate of this issue
Author

Added subscriber: @ParrotDenis

Added subscriber: @ParrotDenis
dono dono changed title from Font Bold, Italic doesn't work to Change Font in Bold, Italic doesn't work 2019-07-13 15:05:45 +02:00
dono dono changed title from Change Font in Bold, Italic doesn't work to Change Text Font in Bold, Italic doesn't work 2019-07-13 15:16:25 +02:00

Added subscriber: @rjg

Added subscriber: @rjg

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- [x].use_italic = True, where "Text" is the name of the object and the index in body_format- [x] is the character you want to change. See the API docs for more formatting options.

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- [x].use_italic = True`, where "Text" is the name of the object and the index in `body_format- [x]` is the character you want to change. See the [API docs ](https://docs.blender.org/api/current/bpy.types.TextCharacterFormat.html#bpy.types.TextCharacterFormat) for more formatting options.

Added subscribers: @ideasman42, @pablovazquez

Added subscribers: @ideasman42, @pablovazquez

@ideasman42 @pablovazquez am I correct with this assessment?

@ideasman42 @pablovazquez am I correct with this assessment?

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Dalai Felinto self-assigned this 2019-07-13 17:33:03 +02:00

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

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

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!

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!

Added subscriber: @Cremuss22

Added subscriber: @Cremuss22

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

@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!
Author

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.

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.

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

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.

@WilliamReynish wants to visit this for 2.81?

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. @WilliamReynish 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 @ParrotDenis on trying to spot these issues in Blender.

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 @ParrotDenis on trying to spot these issues in Blender.

This comment was removed by @rjg

*This comment was removed by @rjg*

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

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

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.

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.

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 #66861#720734, @rjg wrote:
@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 #66861#720734, @rjg wrote: > @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 #66861#720735, @ParrotDenis 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.

> In #66861#720735, @ParrotDenis 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.

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

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.

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

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

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

Added subscriber: @Soldier_66

Added subscriber: @Soldier_66

This comment was removed by @Soldier_66

*This comment was removed by @Soldier_66*

Added subscribers: @JulianEisel, @SimeonConzendorf

Added subscribers: @JulianEisel, @SimeonConzendorf

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. @JulianEisel 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 - [x]Text in Blender[/b] great again."

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. @JulianEisel 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 - [x]**Text in Blender**[/b] great again."

Added subscriber: @jhol

Added subscriber: @jhol

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")
**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") ```

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

@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).
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#66861
No description provided.