Problems with entering non-Latin characters in the input line on Android/iOs

Help
#1

Hello, maybe the topic was already raised earlier and was solved, but I’m looking for a solution and can not find it.

In our project I use openfl.text.TextField with textField.type = TextFieldType.INPUT; and the input line incorrectly handles all characters except Latin letters and numbers.

This topic is not about displaying, but about editing text. The carriage is visually set to the wrong position when I click on the text box. The problem is reproduced when editing any non-standard characters. At the same time they (characters) look correct.

Screenshot_20180110-124808
Screenshot_20180110-124808.jpg1080×898 201 KB

On the first screen shot, I clicked on the end character in the input line and the input carriage was displayed correctly (the correct display occurs when the user clicks on the input field, but not in all cases.) Sometimes when you click on a field, two input carriages are immediately displayed - one at the correct position a another somewhere in the middle of the text in the input field)

Screenshot_20180110-124818
Screenshot_20180110-124818.jpg1080×928 200 KB

Further, if I start to press “BackSpace” the carriage immediately jumps as shown in the second screen shot. Further, the input carriage behaves like letters in the input field thinner than they are displayed on the screen.

Please tell me how to fix this or work around this problem.

EDIT: I tested several different fonts in different formats, including the default ones, the problem is the same.

image
image.jpg1080×324 63.3 KB

Now I caught this rare case with two entry carriages.

#2

Do you get the input value properly (textField.text)? Is this a bug only with the caret, or more?

#3

I create the text field like this:
var textFormat:TextFormat = new TextFormat(Assets.getFont(“fonts/Akrobat-Regular.otf”).fontName, 40, 0xFFFFFF);

var textField:TextField = new TextField();

textField.type = TextFieldType.INPUT;
textField.wordWrap = false;
textField.selectable = true;
textField.multiline = false;
textField.embedFonts = true;

textField.text = “В знак благодарности мы Вам скидку 10%”;

textField.defaultTextFormat = textFormat;
textField.setTextFormat(textFormat);
textField.antiAliasType = AntiAliasType.NORMAL;
addChild(textField);

It seems that this bug appears only for the caret. At least I did not notice other bugs.

When I get the values of the input field (textField.text), I see the same value that is displayed on the screen.
Bugs are the same, not depending on whether the “Entered text” or “text specified by software” (ie, by equating textField.text = “lalalalala”)

For the experiment:
I equated textField.text = “1234567890” (For example, i took the numbers for simplicity, in fact, the numbers do not bug and in TextField i have some ciryllic symbols).
I added MouseEvent.CLICK listener to the text box.

When I click on zero, the caret is placed after it. But then when I start to press “BaсkSpase” the entry caret jumps to 5 but zero is deleted.

And one more interesting point: if I click at the end of the line, I get the caretIndex = 42, although there are only 3 characters in the line (it seems like the maximum number of characters per line), then the carriage is set correctly (after the last character), if you click on the last character then the carriage index = 3 and the carriage is set incorrectly.

In this case, if there is only one character in the line, then the carriage is set correctly.

#4

Would you mind opening an issue on https://github.com/openfl/openfl?

We made a lot of Unicode text improvements, as well as rendering, but I believe it may be because we went from having one input character == one rendering glyph to having multiple characters possibly being combined by our text layout library. As a result, we will need to improve how we translate between character indexes and where it actually exists in the layout

1 Like
#5

Thanks for the answer.
There are really a lot of improvements in text fields, I’ve been watching this for a long time.
I’ll try to open the issue on GitHub, although I did not do it before, when I prepare a detailed description of the problem.

#6

I open a issue, please do not kill if I did something wrong.

1 Like
#7

There is the same problem