TextMeshPro ignoring non-breaking space

It used to be the case that using a non-breaking space -- \u00A0 -- at the end of a line in TMP would take it into consideration for alignment, the same way spaces at the beginning of a line are.

As of the last version at least (3.0.1), this is broken, and all my perfectly aligned text is a mess. Is this function going to return in a future update?

 

For reference, can you provide the raw text along with image showing how you are trying to format / align it?

 

I attach screenshot, but basically, no unicode characters for NBSP or tab or any of those work in the latest version. They did before and stopped working without anything being changed on my side.




As you can see, since the text is centred, it moves everything to the right when the '+' is replaced by ' \u00A0' as if there were nothing after the 7. The text is changed in code thus:

Code (CSharp):

1. if (startSpeed == 1)
2.         {
3.  
4.             textBox.text = "    speed: 1   +";
5.  
6.         }
7.         else if (startSpeed == 7)
8.         {
9.  
10.             textBox.text = "-   speed: " + startSpeed.ToString() + "    \u00A0";
11.  
12.         }
13.         else
14.         {
15.  
16.             textBox.text = "-   speed: " + startSpeed.ToString() + "   +";
17.  
18.         }

It doesn't work either if I change all the trailing spaces to '\u00A0' -- simply ignoring the unicode characters. Using the unicode characters before text works fine.

Thanks!

 

Any idea, @Stephan_B ?

 

I need to take a closer look at this to see if I can provide a short term solution.

The longer terms solution is to provide control over how white spaces are treated at the end of lines of text.

I am traveling right now but will be back Friday night and will try to take a look over the weekend. Sorry about the delay.

 

That would be fab!

 

@Stephan_B still seeing this problem in TMP 3.0.3 — any updates?

 

Currently looking into this. Will provide an update as soon as I have a solution.

 

I just made a first pass at adding support for controlling how whitespaces are treated at the end of a line.

As such, I replaced the existing Wrapping option by a new "Text Wrapping Mode" drop down as follows:



- Normal is the same as the previous Enabled.
- No Wrap is the same as the previous Disabled.
- Preserve Whitespace will consider whitespaces at the end of a line for the purpose of alignment and preferred width.
- Preserve Whitespace No Wrap is the same as above but without wrapping.

The previous "enableWordWrapping" property will be remapped to this new "textWrappingMode" property.

Could you all please submit a few text strings that you are currently using to achieve special alignment / formatting? This will help ensure I don't overlook any special cases.

 

Great, thank you!

Here are some strings --

This is left aligned:
"<b><size=42>Unit Name</size></b>\n<size=32> </size><size=38>HP: 00/00</size>\n<size=34> : 8 : 8 : 8</size>"

This is right aligned:
"<b><size=42>Unit Name</size></b>\n<size=38>HP: 00/00</size><size=32> </size>\n<size=34> : 8 : 8 : 8</size>"

The two should be opposite each other and create a symmetry:

Code (CSharp):

1.  
2.   Unit Name                                                Unit Name
3.         HP: 00/00                                    HP: 00/00
4.       : 8      : 8      : 8                    : 8      : 8      : 8
5.  

Code (CSharp):

1.  
2. +-----------------------------+        +-----------------------------+
3. | Unit Name                   |        |                   Unit Name |
4. |       HP: 00/00             |        |             HP: 00/00       |
5. |     : 8      : 8      : 8   |        |       : 8      : 8      : 8 |
6. +-----------------------------+        +-----------------------------+
7.  

The empty spaces are there to be filled by icons representing the unit's stats.

From earlier --

Center aligned:
" speed: 1 +\n" + "- speed: 1 \n" + "- speed: 1 +"

These should be centred with each iteration of "speed" being nicely one below the other (there might be a small difference on non-monospaced fonts):

Code (CSharp):

1.  
2.     speed: 1   +
3. -   speed: 1
4. -   speed: 1   +
5.  

not like so:

Code (CSharp):

1.  
2.     speed: 1   +
3.   -   speed: 1
4. -   speed: 1   +
5.  

Thanks again for looking into this and building in more flexibility into TMPro to suit a variety of needs!

Edit: I had to change the examples to code blocks, because otherwise the forum itself messed up the alignments...

 

Any update on when this might show up?

 

In the first preview of the next release series which I would like to have available within the next 10 - 14 days.

 

How is it possible to get the preview builds?

I just updated the project to 3.0.4, but it's not there, and Package Manager is only showing verified versions of TMPro, no preview builds -- I do have Package Manager itself set to show previews, and am using quite a couple of those with other packages.

Thanks!

 

Now that version 1.5.4, 2.1.4 and 3.0.4 have been released, I am back to working on the next preview releases which includes the new Text Wrapping Modes.

I would like to have these new preview releases available by the end of the week or early next week.

 

Any update on this?

Almost two months have passed and 3.0.5 has come, but still no preview release -- as far as I can tell. If I'm wrong, please let me know where I can find it, as I don't see it in Package Manger! Thanks!

 

Not there yet but getting closer.

Currently waiting on some changes to the FontEngine that are needed for the next preview to land in the various versions of Unity. Once those have landed, I can then finish and release the first preview.

 

Thanks for the update!

 

Scenario
(There are workarounds but they shouldn't be needed.)

The following rich text displays 'Small Text' at full size, not at 67%, as the non-breaking space (shown as NBSP) is ignored, which it should not be.

<color=#212B56ff><size=67%>

Small Text

</size>

<color=#ff0000ff>

NBSP

</color></color>

The 'Small Text' and 'NBSP' text are replaced programatically. Multiple instances of the TextMeshPro UI are displayed within a vertically stacked menu. It looks very odd having one menu item larger than the rest.

\u00A0 should be excluded from any set of whitespace characters used to omit displayed text. It should be treated as a drawn character even though there are no visible pixels.

Thanks!

 

I tested the above text and the Small Text is 67%.

What version of TMP are you using?

Can you provide more details or perhaps a repro project or scene for me to look at?

 

Seems like trailing whitespace is not handled the same as whitespace within or at the start of the text.
e.g. the <mpspace> tag and Text Wrapping Modes seem to ignored on trailing whitespace.
I'm using the 3.2.0-pre3.

 

Here's a screenshot that should illustrate the issue.
I expect these 2 text fields to line up exactly

 

Any idea when 3.2 might come out of pre-release, @Stephan_B ? It's getting close to two years since 3.0 came out!

 

Yes, the amount of pre-release versions since the last stable release is staggering... Meanwhile whitespace is breaking totally erroneously...

 

Version 3.0.6 which is verified was released in April 2021.

The first preview of version 3.2.0 was released in August 2021 with the latest being version 3.2.0-pre.3 released in March 2022.

There is no firm ETA on when version 3.2.0 will be out of preview as there are still major key features being added like support for OpenType Layout features which is essential to support many non Latin languages and Emoji modifiers.

Please note that what is in preview in version 3.2.x are the new features. The rest of the package is deemed stable in terms of the core functionality and also includes many bug fixes for issues reported in 3.0.6.

 

When using "Text Wrapping Mode - Normal" or "Text Wrapping Mode - No Wrap", white spaces at the end of a line will be ignore just like they are in Microsoft Words or Google Docs.

When using "Text Wrapping Mode - Preserve WhiteSpace" or "Text Wrapping Mode - Preserve WhiteSpace - No Wrap", white spaces at the end of a line will not be ignored.

White spaces in the text (ie. Not at the end of a line will be handled as spaces).

Non-breaking spaces are spaces but prevent line breaking unless there is not other place to break the text at which point we are breaking per character.

Let me know if this makes sense to you or if I am missing something.

 

Any chance the text wrapping modes (specifically preserving whitespace) could find their way into the 3.0.X branch, if 3.2.X still has ways to go?

Thanks for the update!

 

Unfortunately not as once a preview is released all subsequent fixes and features go in the next preview which in this case would be preview 4.

 

Yes you are missing the info in my previous comment i.e. that the monospace tag does not affect this "preserved" whitespace.
In the image I'm using the "Preserve Whitespace" setting but whitespace before the text is not the same width as after the text.