TextMesh Pro TMP: Breaking Chinese Bugs for Traditional ZhuYin ("BoPoMoFo" - Taiwan Locale)

When using TextMeshPro InputFields for traditional Chinese in Taiwan (called "ZhuYin" or "BoPoMoFo" where you use a combination of phonetics and numbers [indicating tone] to make characters), there are some dominant (but random) bugs:

Screenshot:



Screencast:

https://recordit.co/2e5R5meUn5

Referencing the screenshot above:

1. Click in TMPInputField
   
   
2. 1st char will be in Chinese (normal)
   
   
3. 2nd char will become English (expected: Chinese) -- indicated in the example screenshot; notice the number 5, followed by 2 Chinese characters.
   
   
4. If you unfocus the TMPInputField (click away) and return, it'll work for until you submit once -- then steps #2 and #3 (above) will be repeated. There are no special OnValueChange() events associated with this TMPInputField. Submitting will only clear.
   
   
5. If you continue to focus the TMPInputField and type characters, the 1st char will always be an English character until you unfocus >> refocus (then the bug returns after the 1st line).

• Anytime you see an English char or number @ char[0], it's bugging out.
  
  
• Both the TMPInputField and the submitted txt contain the buggy str (which is why it also reflects in the chat, which is also a read-only TMPInputField)

EDIT: Similar post reported in 2018:

https://forum.unity.com/threads/bugs-happen-when-typing-chinese-words-in-editor-and-ui.600541/

 

Thanks for the feedback / report.

There are a few issues related to IME that have been present for a while now. These are not specific to TMP or even the legacy text system but to IME handling which is handled by the Input team.

I will be talking to the Input team shortly and will be sure to bring up these issues as well.

I'll post back once I have additional information.

 

Ah, thanks for looking into this!

 

Hi @Stephan_B , any chance you have a timeline estimate on this? I'm approaching an awkward point where I must soon decide if I should try to find a ghetto workaround or if I should wait for a fix. We're currently in alpha for Chinese testing. Let me know if you require additional details.

Apologies for the pressure! Just trying to plan

PS - have any temporary workaround suggestions that would be easy to revert later upon a fix?

 

I will take a look over the weekend and provide feedback no later than Sunday night.

 

Can you check if you are getting the same behavior in any Editor text field / inspector? Also please see if you get the same behavior in the UI Input Field.

What character sequence / keyboard keys are you typing to reproduce these behavior?

Whenever the input field is un-focused, IME is disabled. However, whenever you re-focus the input field, IME is not re-enabled. Right now I have to use CTRL + Spacebar to re-enable IME.

There are definite issue with the IME input system.

 

I'll be able to test in a couple days and get back to you~

 

@Stephan_B Ok, I got my wife to help out (my Chinese is limited, especially Bopomofo [Taiwan, Traditional Chinese] IME):

Code (CSharp):

1. ㄏㄏ>> c space c space
2. 寮>>xul6
3. 監>>ru0 space
4. 視>>g4
5. 中>>5j/ space
6. 文>>jp6
7. I tried to type "中文" again but it  change to english automatically, so it showed "5" at the next line
8. 翁>>j/ space
9. trying to type "中" again, and it worked
10. trying to type "中" again, it falled and show as "5翁"
11. (when I type 中, it stared with keyborad "j". )
12. trying to type "文(jp6)" but it show as "j恩"
13. how to type 恩>> "p space"
14. If you need more info or how you want as to type, let me know. Thanks
15.  

I'm too deep in a messy project to test anything else, yet, but hope this helps.

 

I'll re-test these.

Were you able to test this in a normal text field in the Editor in some inspector?

 

Seems fine in the inspector, so far. By normal, you mean a TMPro UGUI, opposed to inputfield, right?

To add, I'm also noticing some weird stuff relating to copy+pasting of traditional Chinese characters (possibly any unicode). If I paste some characters inside an editor text field, it'll show as something random. However, if I ctrl+Z, the entire txt is wiped EXCEPT for what I was originally trying to paste!

 

To update, what may or may not be related, there's another at least semi-related issue:

Within the editor, I often cannot copy+paste Unicode values to each other (specifically, to a TMPro UGUI) -- without doing something hacky. Sometimes it works, sometimes it doesn't. However, right now (even after a reboot), it won't:

• If I copy unicode from outside of Unity, it works fine.
• If I copy unicode from within Unity to within Unity (eg, from a ScriptableObj to a UGUI text field), this is what happens:

• ^ What's happening above is me trying to copy+paste the Chinese version of "Sheriff" ( 警長 ) from a ScriptableObject to a TMPro UGUI Text field: When I paste the value, the unicode is replaced with "fw". You can see me copy+paste "asdf" no problem (ASCII English).
• If I copy FROM Unity to OUTSIDE Unity (eg, notepad), the result is also "fw".
• If I try to copy a different Unicode from within Unity to Unity, such as "Marshal" ( 刑事官 ), nothing is pasted at all when: In fact, right clicking won't even show a "paste":
  

It seems that issues with Unicode extend to the Editor -- but it's not entirely clear what's causing it (I don't have enough time to check patterns further, unfortunately)

EDIT: To rule out my ScriptableObject having issues, I'll repro this breaking FROM tmpro ugui to tmpro ugui:

1. copy+paste FROM Notepad TO TMPro UGUI.
2. Copy from TMPro UGUI to TMPro UGUI. It will not work.



HOWEVER, notice at the end i got it to show -- sort of: If I CTRL+Z, the field wipes and is replaced with what was *meant* to be pasted. However, this means I cannot paste within the middle and CTRL+Z or any accompanied text will wipe EXCEPT what was supposed to paste.

So pasting Unicode from plaintext Notepad to a Unity TMPro UGUI Text field will permanently do something very strange to the text. I can no longer copy+paste it anywhere:

I cannot paste Unicode vals from within a TMProUGUI Text field anywhere within Unity -- and even externally. Pasting here or back to notepad results in an empty paste.

 

Thank you for providing all this great feedback.

I am slowly going through all of these. Some of these issues have been in Unity since Unity 4.x so tracking those with knowledge of those implementation or getting up to speed on my end on those IME related implementations is slow.

Please keep on posting in this thread as you uncover additional issues.

 

When I try to paste from Unity to Unity:

`儲存至桌面為`

The following is, instead, displayed:

`2X`

If I paste here, here's what's displayed:

`2X` (Notice the +secret tofu box)

EDIT: Tofu isn't showing. Here's what I see:

 

By 2X, you mean duplication of the composition sequence? If that is the case, I did resolve that issue which has been in Unity since at least 5.x.

P.S. I am focusing on the TMP Input Field issues first and not necessarily Editor / Inspector issues. However, in the case of the duplication issue, I did fix that one in Unity so it is also fixed in the Editor. Editor / Inspector specific issues, I will be passing to the Editor team.

 

Oops, no, just a literal string. I wonder if it would partially match a /unicode sequence. I'm not good with that, though, so no idea.

 

Just wanted to do a quick follow-up: Any luck?

 

Hi, I had already filed a bug report regarding this issue one year ago. It was a bug that had existed at least from Unity 5.
The support told me that they were working on the new input system, however, after checking the new input system that is currently in alpha, I don't think this new feature is relevant to this issue. This issue is about Unity's mishandling of IME, and the build-in input field UI and the editor input field are using the same system, they both exhibit the same bug.
I am developing a Chinese word game, and most of my players are using Microsoft Bopomofo to type Chinese. This bug is extremely crucial for me. I am still waiting for the official fix to this issue.
This was the thread that I posted one year ago:
https://forum.unity.com/threads/bugs-happen-when-typing-chinese-words-in-editor-and-ui.600541/

Edit: I have just seen that Stephan_B said that he had resolved that problem. He was able to reproduce the issue when we discussed on my thread. So glad to hear that this issue would be fixed sometime soon. (although it has been another 4 months since the end of this thread...)

 

We're still getting this, too it's become critical now. There are so many weird bugs. Just try switching to Chinese IME and type -- both Taiwan Bopomofo and PinYing both have some serious, serious issues.

Unity is the ONLY game engine used in Taiwan (many don't even know about Unreal at all) -- hopefully this becomes a priority soon.

EDIT: Just saw the edit above; that's fantastic news - where can I find this fix?

 

Just wanted to follow up - any progress on this? Or if it's fixed, is it already on the current preview?

*Ignore attached image - can't seem to remove it

 

ok, to follow up - I tried preview 4. Seems like this MAY have resolved the major bugs in the editor, but haven't built yet or done any testing with our actual Chinese community. Just initially. HOWEVER...

Typing in Unicode will, for some reason, prefix and suffix <u> and </u>, respectively:



You can repro this by typing the letter "x" with Chinese IME (any form - PinYin or Bobopomofo) and as the suggestions popup, you'll see the <u>{pendingTypedMsg}</u>. You can see it more clearly if you press backspace once:



I'm going through my code to make sure I don't have something REALLY WEIRD lingering from an old dev, but I really think it's not me.

EDIT: Upon testing with OnValueChanged for the TMP_Input, I discovered that OnValueChanged doesn't trigger at all when the <u> appears.

EDIT 2: Hmm, can't repro this minimally. Seeing what's different. It's strange because OnValueChanged doesn't even trigger when I'm doing this, so where could this possible happen? It feels like a hidden style to wrap around it like that.

EDIT 3: I noticed that if you alt tab while you're 1/2 way selecting a character, the placeholder will show, stacking on top (repro'd minimally)



EDIT 4: Waaaitttt a second..... are you noticing the underlined portion? I bet I can repro this by disabling rich text!!

 

Apologies for the spam, but replying on a new block for a breakthrough with a minimal repro ( @Stephan_B ) for 2 bugs:

1. `<u>bug</u>` during character formation is caused by rich text:



Important: The expected fix is to still underline the text when character crafting (I don't know the official term for this; whenever you're mid-selection with the popup menu). However <u> should not be used.

It seems like IME selection wraps with a <u>. Instead, it should be explicitly underlined instead of using a <u> wrapper.

2. The stacking placeholder text with IME selection text:



Whenever you start "character crafting", the placeholder text correctly hides. However, as soon as I alt+tab and return, the unfinished character crafting is not detected and stacks with the placeholder text.

EDIT 1: Unicode has a ton of weirdness that I can't yet explain beyond even these. I'll get back to you. Eg, this only happens with Unicode:



EDIT 2: One thing is for certain: Unity needs to fund you a Chinese IME QA tester. While I'm cool submitting these to you, it's not very fair to the gamedev's end-users that shouldn't have to wait for fixes for common issues [common to a Chinese user] that shouldn't exist. Since neither of us are Chinese, it's sort of hard to come across real bugs. Unity claims full Chinese support -- let's hope they give you some +QA to help reinforce this claim (assuming you're just one person patching TMPro).

 

More related repro:

If you type in the TMP_Input text directly (prefill within the editor) and FINISH your character (press 1 or spacebar at the suggestion popup), you get an extra character duplicated outside the <u> wrapper:



This actually gets confusing very fast, so while there's a static screenshot below, here's a GIF showing multiple combos. To test, I'd just add Traditional Chinese (Taiwan) PinYin IME and try a few combos. In the example used, just type "xue".

*The GIF above represents what happens both playing AND in the editor with the <u> wrapping with the exception of the "extra" dupe character on the right that's only found in the editor.



Expected: "學"
Actual: "<u>學</u>學"

I will be watching this thread daily: We're now in Chinese beta, so Unicode bugs are spewing out like a fountain and happy to work with you to get these fixed as soon as possible.

 

Just wanted to follow up on this breaking issue: I should hopefully have provided sufficient info to resolve it. Seems like it's simply a rich text <u> underlining at IME character suggestion popups that should manually underlined (or ignored completely as a temporary workaround if rich text is disabled). Any luck?

 

May have found it:



As a temporary workaround, I'm going to guess I can comment this out? Or even better workaround would be to check if rich text is enabled (m_TextComponent.richText?) since the line shows normally when that happens. I'll look around.

So as for the REAL fix, it would be some type of "override" where your <u> (in this particular instance) would underline it no matter what, but not treated as rich text. This way, users can still enter input with !richText and still see IME underlines.

 

That temporary workaround did the trick:



Note that there is no longer a `<u></u>` wrapper around the input caret when IME character is being selected.

Here is the code:

Code (CSharp):

1. // TMP_InputField.cs:3093
2.  
3. // [OLD] This is bugged out when rich text is !enabled
4. //if (compositionLength > 0 && m_ReadOnly == false)
5.  
6. // [NEW] Only wrap <u></u> with richText enabled:
7. if (compositionLength > 0 && m_ReadOnly == false && m_TextComponent.richText)

See screenshot in previous bump for further reference.

 

I'm surprised this wasn't reported ages ago by the Chinese community~ Are they using the old text system or something? We got bombed with reports from quite literally 30% of our entire Chinese community almost instantly with the Unicode issues.

Do you guys have a Unicode tester trying out all kinds of combos?

 

I am Chinese, and I was also surprised that Unity didn't get bombed with bug reports regarding this issue, given that how big the Chinese user base is. Hearthstone is also developed using Unity, the desktop version of Hearthstone also has this bug. I don't expect that we can find any perfect workaround. Although Stephan_B had said that he had resolved the issue, but the issue still exists in 2019.3. If we are using Unity engine to create Chinese word game and it's on desktop platform, don't use Unity InputField as the core gameplay, it's unusable in Chinese.

 

I am aware of the <u> issue when rich text is disabled. I just need to find the time to figure out a good solution for it. Until then, it might make sense to disable this underlining which is causing issues.

Note that I am reading all these posts but like I said before don't always have time to reply but I am reading so keep the information / feedback coming.

 

Haha we have exactly that: An online text-based social game ;D We've implemented my workarounds mentioned above and it works, but it can be easy to get "lost" in your IME without an underline being there. At least it works, though. Surprised Hearthstone couldn't find a fix. For deck names or something?

Now to remember I embedded the package for future fixes ...

 

HI, I have the same issue,has it been fix? my version is 2.1.0-preview.8.

 

The <u> and </u> should no longer be visible when disabling Rich Text on the Input Field. It is still possible to get that while editing the IME composition. If that remains an issue, the following lines of code can be changes in your global package cache until I have a more permanent fix.

In the TMP_InputField.cs file around line 3134, make the following changes.

Code (csharp):

1.  
2. // Replace the line below
3. if (m_RichText)
4.     fullText = text.Substring(0, m_StringPosition) +  "<u>" + compositionString + "</u>" + text.Substring(m_StringPosition);
5. else
6.     fullText = text.Substring(0, m_StringPosition) +  compositionString + text.Substring(m_StringPosition);
7.  
8. // By this single line
9. fullText = text.Substring(0, m_StringPosition) +  compositionString + text.Substring(m_StringPosition);
10.  

In terms of the permanent fix, I need to re-work a big chunk of the input field to isolate the user input from the internal text used for display. This would enable the developer to still use rich text for coloring, etc. while being able to disable rich text from the user's point of view.

 

HI,@Stephan_B,my issue same as #11,i can't input any Chinese with IME in unity editor and win standalone.
I use the new input system(1.0.0-preview 6), is this a reason for the issue?

 

That could be an issue and make sure you are using the latest release of the TMP package which is Preview 8.

 

@Stephan_B This bug is breaking, and seems to still exist (unless it was fixed really recently - last month):

1. Sometimes Chinese IME (BoPoMoFo / sometimes called ZhuYin) will replace the first character with an English one.
2. If you finish a sentence, but didn't press <enter>, the Chinese sentence will automatic type twice.
3. After #2 when the input dupes, you need to use ctrl+space to change back to Chinese (seems like it throws them in English IME?).

I'll have a new video soon. You can also ask tons of people that experience it directly here: https://discord.gg/tad28XF

You may @ping or possibly direct message DoubleHeat_TW , or ask in #general (many folks speak English and are dying to get this fixed, so they'll help you) while waiting for a response.

 

I did fix most IME issues in 2018.4. I still have to get those fixed in 2019.x or newer which I didn't do because of the New Input System.

So please check if the behavior is correct in 2018.4. If it is then I'll try to get this fixed once and for all for the newer versions of Unity.

 

Ah I cannot currently test earlier versions of Unity - I only have the time for smaller tests. With the new release of Chinese support, I'm currently flooded with work. Is it possible to snag a Unity QA for this one?

However, when we first discussed this in 2019, I was using an earlier version of Unity. At one point, I stopped responding here because I thought it was fixed. MAYBE it really was fixed in an earlier version before I upgraded (I'm now on 2020.1).

If you have any smaller tests for me todo to speed things along, give me a shout.

 

Let me get these fixes in 2019.x and 2020.x. I'll try to get this done over the next few days and provide an update once it is done.

 

Video @ https://cdn.discordapp.com/attachments/756459120743284776/758586590791729183/zh_1st-key_bug.mp4

Video @ https://cdn.discordapp.com/attachments/756459120743284776/758587609961988096/zh_duplicated_bug.mp4

 

Let me know if you get delayed - not to add pressure, but I'm going to wait on this update before our own update. I think this is the top hurting point for Unicode right now. Let me know if you have any questions and I'll try to ask the community that uses this.

 

Looking forward to the future fixes, it's been almost two years since I filed a bug report to this bug. Hope that it will get fixed before I celebrate Happy Birthday to my bug report.

 

I'm checking this thread daily, now I'm suddenly a bit desperate. It actually worked in a previous version, so thought it was good to go. It was a bit embarrassing when I told the community it was fixed and realized it was not when I upgraded Unity shortly after D: I wish there would be more Unity QA assigned to support Stephan for Unicode testing: Chinese is supposed to have full support, but Stephan seems to be the only resource available to fix em.

Many of the core bugs are fixed now [after this one], but it's been a longggggg journey... I should really send Unity an invoice for all my time invested in the bug reports/repros for Unicode issues, alone. Must be a combined 100 hours. I really hope you get more QA on your journey, Stephan~ you shouldn't have to bare this alone when Unity is such a giant, ever-changing project (and devs/end-users shouldn't need to wait a year for basic Chinese support when Unity advertises it supported).

 

How goes it?

 

I have a fix in flight for 2021.x awaiting approval. Once approved, I'll submit the backport for 2020.2, 2020.1 and 2019.4.

I'll provide an update once those are all on the way including in which respective versions of Unity these will be available in.

 

Very nice - what would you say would be the next realistic ETA for the 2020.1 patch? Trying to plan~ Thanks!

 

Not sure yet. It will most likely be a few days before the changes land in those different versions of Unity and then perhaps a week to 10 days or so before those are released.

 

The above fix just landed and will be available in the following Unity releases: 2019.4.13f1, 2020.1.9f1 and 2020.2.0b7.

 

Nice!! I'll keep an eye. Anyone know when to expect 2020.1.9? I saw the link to beta patch notes expired, so maybe soon?

 

Seems like 2020.1.8 just came out the other day. Seems next.

 

New ver is out!

 

July 27? Is this the one? Something doesn't feel right about the date ... I was sure to unembed my old one with Unity closed and allow Unity to update it when reopened. Went from an embedded 3.0.0 >> to new 3.0.1 which is a new version, but not sure if the version. I'll test it soon.