Korean input bug in UWP build

[djqandyd1653]

Hello, I built with UWP to launch a game on MS Store.

However, if you enter Korean in the input field of textMeshPro in the UWP build, the consonants and vowels are separated and displayed.
ex) Expected results: “가나다”, Actual results: “ㄱㅏㄴㅏㄷㅏ”

Strangely, It will print normally when you try it in Unity Editor.
In addition, the touch keyboard in the UWP build will output normally.

If you know how to solve a bug like this, please help me.

Unity Version - 2021.3.8f1
TextMeshPro Version - 3.0.6
Build Type - XAML Project
Platform - Universal Windows Platform(UWP)

[MelvMay]

This isn’t my area but you should be aware that there is a dedicated TMP forum here: Unity Engine - Unity Discussions

I can move your post if you wish?

[djqandyd1653]

@MelvMay

This isn’t my area but you should be aware that there is a dedicated TMP forum here: https://forum.unity.com/forums/ugui-textmesh-pro.60/

I can move your post if you wish?

Yes i wish. thank you

[MelvMay]

Done!

[timke]

Thank you for raising this issue!

I’ve done a lot of work with UWP’s TouchScreenKeyboard and IME implementation in the past.
This definitely sounds like a bug with UWP and so please file a Unity bug if you haven’t already.

Strangely, It will print normally when you try it in Unity Editor.

This is because UWP uses a completely different platform implementation than the Editor and Windows StandalonePlayer; it uses WinRT instead of Win32. Strangely enough UWP != Windows

In addition, the touch keyboard in the UWP build will output normally.

That is odd, because TouchScreenKeyboard and IME are provided by the same WinRT API, specifically CoreTextEditContext, and so Unity’s implementation handles both scenarios.

Anyway, I doubt this is a TMP issue, but we’ll need a bug report in order to investigate.

[djqandyd1653]

@timke

Thank you for raising this issue!

I’ve done a lot of work with UWP’s TouchScreenKeyboard and IME implementation in the past.
This definitely sounds like a bug with UWP and so please file a Unity bug if you haven’t already.

This is because UWP uses a completely different platform implementation than the Editor and Windows StandalonePlayer; it uses WinRT instead of Win32. Strangely enough UWP != Windows

That is odd, because TouchScreenKeyboard and IME are provided by the same WinRT API, specifically CoreTextEditContext, and so Unity’s implementation handles both scenarios.

Anyway, I doubt this is a TMP issue, but we’ll need a bug report in order to investigate.

Thank you for your answer. I just created a bug report.

[djqandyd1653]

@timke

Thank you for raising this issue!

I’ve done a lot of work with UWP’s TouchScreenKeyboard and IME implementation in the past.
This definitely sounds like a bug with UWP and so please file a Unity bug if you haven’t already.

This is because UWP uses a completely different platform implementation than the Editor and Windows StandalonePlayer; it uses WinRT instead of Win32. Strangely enough UWP != Windows

That is odd, because TouchScreenKeyboard and IME are provided by the same WinRT API, specifically CoreTextEditContext, and so Unity’s implementation handles both scenarios.

Anyway, I doubt this is a TMP issue, but we’ll need a bug report in order to investigate.

Automatic response just send me “Your request status has changed to Closed with resolution Not Qualified.”
Is there any resolution to solve this?

[timke]

I looked into what happened and apparently there was some kind glitch in the process.

Ticket IN-17424 (one that was closed) was determined to be a duplicate of IN-18130, which is still open and has been promoted to an official bug. Closing the duplicate ticket as “Not Qualified” was a mistake and QA incoming said they’ll work to fix the issue.

I’m sorry for the confusion (I was also surprised), but I did confirm there is an open bug ticket for this issue.