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.
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?
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.
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.
ArgumentOutOfRangeException: Selection is out of range.
Parameter name: selection
at UnityEngine.TouchScreenKeyboard.set_selection (UnityEngine.RangeInt value) [0x00000] in <00000000000000000000000000000000>:0
at TMPro.TMP_InputField.ActivateInputFieldInternal () [0x00000] in <00000000000000000000000000000000>:0
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.
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.
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.
I should be able to try it in the next days.