TextMesh Pro Bug with Ellipsis overflow when using a font fallback (IndexOutOfRangeException)

Hi @Stephan_B,

We found a bug that happens in very specific conditions. Attached you will find a small project (as small as we could make it) made with Unity 2019.2.11f1 and TextMesh Pro 2.0.1.

It contains a single scene with the text "ERROR" written on a TMPro UI text. The text has wrapping disabled and overflow set to Ellipsis (although you can't see the dots yet since "ERROR" is small enough). This text uses a font that only has the underscore and ellipsis characters (the ones REQUIRED by TMPro), but has a fallback to LiberationSans (default TMPro font).

Please open the scene, select the Text element in the inspector and replace "ERROR" with "89bpm_audacity.ogg" (no quotes; just an example). You should get this exception and the displayed text will still be "ERROR":

Then progressively increase the text's width. You should get the same error multiple times until the text is wide enough to contain the string "89bpm_audacity.ogg".

When increasing and decreasing the width you should see that the text can only either be reduced to "89bpm..." or be fully shown, so it seems to break when it finds a character from the main font (not the fallback), in this case the underscore. You can recreate the atlas with a Q instead of the _, for example, and paste "89bpmQaudacity.ogg" (underscore replaced with a Q) and you will get the same problem.

There are some widths and font sizes that cause this problem while others don't. Disabling the Ellipsis overflow also solves it, as does using the fallback font directly. In our actual project where we found this problem we can't exactly do any of these workarounds, unfortunately.

Can you please take a look? Thanks.

Daniel

 

Please test with version 2.1.0-preview.1 which contains significant changes related to how the Overflow modes and Ellipsis are handled.

Preview 2 will be out today.

 

Hey Stephan, we updated to 2.1.0-preview.1 and it has the same behaviour.

We actually had tried this update on the actual project before posting here, but I confirmed just now on the repro project too.

 

I'll take a look tomorrow and provide feedback as soon as I have more information.

 

Are there any news? Sorry to press you.

We are also facing another problem on UWP builds:

It seems similar to this one, but in another method. Happens when pressing an input field (which selects its text), in a touch device or using the mouse (doesn't matter). The virtual keyboard never shows up when using hybrid device with the screen detached from the keyboard.

Do you know if this is fixed in the next non-preview release?

 

@Stephan_B?

What is the preferred process for reporting TMPro bugs? Report them to you here in the forums or do it via the bug reporter? I avoided the bug reporter because it's usually more bureaucratic and takes longer, but through here I'm not sure if you forgot or are just very busy.

 

Bug reporter is always the preferred way as that usually makes it easier to reproduce the issue when a project is included. When using the bug reported, it is also best to provide the case # here so I can get to it faster.

 

OK, next time I'll do that, but I did provide a reproduction project here. If it's easier for you to follow a report via the Unity Bug Reporter (which I didn't do) I understand.

You did tell me you were going to look at this "tomorrow" on the 8th of November, and my follow-up question on the 15th got no reply, so you can see why I'm feeling that this was not the best way to reach you. I confess we've been waiting for your reply in this thread.

Do you have news on either bug? Our project is encountering both, along with some more unrelated regressions in Unity itself.

 

I was able to reproduce the initial issue you reported but still need to look into the 2nd one related to the virtual keyboard.

In terms of the first issue, it is directly related to the primary asset only containing those two characters and use of ellipsis. The clean / optimum solution requires significant changes which I am still working on. Having said that, let me see if I can get you a temporary fix.

Just for my understanding, can you provide more insight on why you are using this primary font asset with just those two characters instead of using a primary font asset that contains the required characters + the underline and ellipsis?

 

Please make the following changes in the TMP_Text.cs file. Make sure these changes are made in the Global Package Cache otherwise the changes will get reset once Unity is closed / re-opened.



Please test the above simple / temporary fix and let me know if you run into any other related issues.

 

Thank you very much for looking into this and providing a fix. I should be able to try it in the next days.

I believe we once talked about our specific setup in the forums but I can't find the thread to link it, so:

We have a special setup because our apps are multilingual and can use Chinese, for example, which requires different fonts. Since we don't want to load EVERY font atlas regardless of chosen language, or have to dynamically switch the used font asset for all text elements (which would include choosing the right/equivalent material in the replacement font), we make use of the fallbacks and auto generation of characters in the atlas.

So all text elements use a "dummy" base font whose fallbacks we dynamically replace with the adequate font assets, loaded only as necessary. Those font assets fill their atlas as necessary. If they fill up completely, we create an additional atlas dynamically. I even had a suggestion related to that here.

Since we want no characters in the base font but TMPro requires those two, we just add those. I'm not confident that the performance we get is the best since all text elements create sub text mesh elements because of the fallbacks and different fonts, but it works well in our experience.

If you have questions about this feel free to ask.

 

Please also test the new Multi Atlas Textures feature which is found in the Font Asset Generation Settings section. This feature is available in the latest preview releases. This feature will create new atlas textures on demand.

 

OK, thanks for the heads up. I'll take a look when possible. Since our setup has been working in production for many months now in multiple apps, there's great friction to change it at this time, but it seems like something I'll want to check.

 

Totally understandable. When you have time and when appropriate let me know how this new feature works for you as it could simplify this process / handling on your end.

 

Hi Stephan, I can confirm that your fix solves the problem in our project. Thanks!

Your line numbers don't match with ours, however, so I did that change in all 3 places where there was similar code, which was FillSpriteVertexBuffers and 2 FillCharacterVertexBuffers methods. All seems fine for now.

You were probably basing the diff on your version, which is likely the preview. Ours is 2.0.1.

 

@CanisLupus Did you manage to solve the 2nd error with inputfield selection? I'm encountering the same problem in my project in UWP build. It's crucial for my upcoming release.

Code (CSharp):

1. ArgumentOutOfRangeException: Selection is out of range.
2. Parameter name: selection
3.   at UnityEngine.TouchScreenKeyboard.set_selection (UnityEngine.RangeInt value) [0x00000] in <00000000000000000000000000000000>:0
4.   at TMPro.TMP_InputField.ActivateInputFieldInternal () [0x00000] in <00000000000000000000000000000000>:0
5.   at TMPro.TMP_InputField.LateUpdate () [0x00000] in <00000000000000000000000000000000>:0

I'm currently using TMP 2.0.1 but I've also tried TMP 2.1.0-preview.3. Unfortunately the problem persists.

Thanks for help
Mike

 

I have another similar issue to look at today so I will also try to take a look at this and provide feedback as soon as I have more information.

 

Hi Mike, if I'm not mistaken we ended up "ignoring" the error since it seemed to not cause additional problems. In our case this is different from "doing nothing about it" because we have an error report dialog that is shown to the user in case of internal errors, so they can send us an email with all the needed info. Unfortunately, this exception triggers the report, so we had to purposedly whitelist it in the reporter.

 

I'm getting this error:

ArgumentOutOfRangeException
Selection is out of range.
Parameter name: selection

• UnityEngine.TouchScreenKeyboard.set_selection (UnityEngine.RangeInt value)
• UnityEngine.UI.InputField.LateUpdate ()

unity 2019.3.0f3
android 8.0.0 galaxy s7

I am NOT using text mesh pro on this input.


Is this related? I have quite a complicated project so recreating this might be tough.

 

Some TextMesh Pro users have reported a similar issue which I believe might be related to changes the New Input System team have introduced in Unity 2019.3 which would affect both TMP and the legacy UI components as well.

We will need someone to submit a bug report with project about this since this issue isn't in TMP or the UI system but likely in the new Input System and whatever code changes occurred there.

 

Got it. If i can narrow it down more i will submit a bug report.

 

I am also getting so many of the same exact crash reported in Unity Analytics. Did you submitted a bug report? I am on Unity 2019.3.11f1 and also not using text mesh pro. Happening on both Android and iOS. A temporary fix is to set the "Hide Mobile Input" property to false in the input field's inspector. By doing this the crash does not happen. An extra native input text appears above the keyboard. But at least the crash does not happen. I tested this fix only on Android.

 

Please submit a bug report as this will help the Android team resolve this as quickly as possible,

 

I can recreate this on IOS also, i submitted a report just now, but can't attach project because it's too large.

 

Thanks for submitting a report, can you please post a link to it here? So that I can see the progress.

 

I'm not sure how to do it correctly. i was told not to link fogbugs in the forums, is there a better way to do it?

 

I'm on Unity 2019.3.13 getting error below for a build UWP (nowhere else observed) when using TextMesh pro input field, I'm on TextMeshPro 2.1.0 prev .13

Code (CSharp):

1. ArgumentOutOfRangeException: Selection is out of range.
2. Parameter name: selection
3.   at UnityEngine.TouchScreenKeyboard.set_selection (UnityEngine.RangeInt value) [0x00000] in <00000000000000000000000000000000>:0
4.   at TMPro.TMP_InputField.ActivateInputFieldInternal () [0x00000] in <00000000000000000000000000000000>:0
5.   at TMPro.TMP_InputField.LateUpdate () [0x00000] in <00000000000000000000000000000000>:0

 

This is a recent issue that has been reported which also affects the UI Input Field. This is not specific to TMP but due to some potential changes in Unity. Perhaps in the Input System or something.

I believe some bug report has already been submitted on this but if you are able to reproduce this issue reliably, please submit a bug report with project and steps to reproduce as this will help expedite a fix for this. If you do submit a bug report, please provide the Case # once you get it via email from Unity.

 

Hi @Stephan_B thanks for sharing. Yep, that's the problem - I have failed to repro and have tried with Unity 2019.3.13, 2020.1.0b8 , 2020.0.a10, ... I only find it in our project and because we had not decided releasing on UWP at the time of starting work on this project I can't tell when the bug started to show for our project

 

tarrag: this happens with inputFields on ios/android when you have Hide Mobile Input enabled, and try and select text while the on screen keyboard is up.

 

thanks @michaeleconomy very helpful to know. We're seeing this only on builds UWP

 

As I have said previously, if you are able to reliably reproduce this issue please submit a bug report with project and steps. Once you get the Case # from Unity via email please post if here and I will follow up with whoever internally to make sure this gets resolved.

 

Here's my case number: 1247399

 

Is there already a nice workaround for error nr. 2 (the ArgumentOutOfRangeException: Selection is out of range issue on UWP)?

I currently have the same issue, also only on UWP. I debugged a little and the error seems to happen if TMP_InputField.cs sets the m_SoftKeyboard.selection range to a larger length than the length of the current m_SoftKeyboard.text.Length. This happens for example if you select a text input with text containing 3 characters, and then select another text input with 5 characters.

Meaning there seems to be some kind of race condition: TextMeshPro wants to update the selection range, but the text property in the soft keyboard still contains the old value. So the IntRange goes outside of the current text range.

There is no exception if I add the following code before setting the selection:

Code (CSharp):

1. if (length > m_SoftKeyboard.text.Length) {
2.   length = m_SoftKeyboard.text.Length;
3. }

But this of course isn't a nice solution as it doesn't solve the basic issue here. The selection would need to be updated after the text property has updated instead. Cheap solutions like setting m_SoftKeyboard.text before updating the selection do not work either (as it probably is asynchronous in the background). I haven't tried my usual Unity-workaround yet (delaying the selection by setting a bool in this case and if the bool is true, checking in the LateUpdate loop if if m_SoftKeyboard.text is already correct, and if yes, update the selection) because it would be a very hacky solution...
Not sure how to do this in a nice way, though. Any idea, anyone?

 

I recently had the same issue in UWP. It seems to work when I set shouldHideSoftKeyboard to true.

 

I ran into the same problem. Still no fix?

 

Can you check if you still run into the same behavior with the latest preview release of the TMP package?

What version of Unity and TMP are you using?

 

Hello, I'm not on a preview version. I'm on Unity 2020.1.8f1, with TMP version 3.0.6. Do I have to switch to a preview version to get this working? I'm worried about the stability of a preview version.