-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selection of any justified-text is inaccurate in non-latin languages #39755
Comments
CC @GaryQian |
It does not have to be a text input to reproduce the issue. Any selectable text would show the same behavior (text inputs, SelectableText, SelectableText.rich ... etc). So I think it's better to remove |
@OsamaAbbas The labels are not exclusive, if it impacts an area or is reasonably relevant, we should add the label so that the right people can find the right bug. This looks like we are somehow missing the justification_x_offset from the code_units in LibTxt. The curious part is somehow, alphabetic text works, which indicates it isn't a blatant omission of the justification_x_offset but rather something more subtle. |
Russian language does NOT have this issue. (I thought it would, because it uses non latin chars) |
A more likely explanation is that some scripts treat spaces as forming a new run of text, while latin script treats spaces as a part of the same run of text. I'm reviewing the justify logic to see how we deal with spaces as a delimiter for runs and if we are justifying properly there. |
I really appreciate your effort. Thank you. Maybe related: Mixed text (latin and non latin characters) breaks the RTL justification but fixes the selection accuracy! However, not all combinations have this effect, some combinations only fixes the selection accuracy on the same line. I did many trials but have not recorded them. By a 'combination' I mean: single latin character, one character plus a space, one word without spaces, multi-words ... etc. |
An important update: changing the font to an appropriate Arabic font (I used Amiri Font) solves the accuracy problem. It also makes spaces have the same height as the surrounding text. I will try with a Korean font later. |
You can now use I recommend trying |
Actually, the issue above only partially resolves this. Reopening! |
Any updates on this issue? This is something we're facing too in Arabic text selection no matter what the text alignment is. It's not just a justification issue, and I think the title should reflect that. We've tried different fonts and no solution. Even on latest release v1.17.1. Thank you. |
flutter doctor -v
|
I have same issue in my project (flutter web) |
Looks like this is still an issue with languages like Hebrew, Arabic Hebrew (Flutter)Hebrew (Native)Arabic(Flutter)Korean single word selectionKorean line selectionflutter doctor -v (mac)
|
This issue is missing a priority label. Please set a priority label when adding the |
I hope I can clarify this issue because it is a little weird. It took me a while to figure out when exactly does it occur.
Here is a very primitive application:
Now, type any latin charachter text. Try to select any single or multiple words, you will find that the selection blue highlight matches accurately the boundaries of the word(s). See this screen shot:
Then, put some Korean text. You will find that some words are poorly highlighted:
Also in Arabic texts (it does not matter here that the
textDirection
is not RTL. Both RTL and LTR have the same issue):Same in Hebrew:
Just copy these texts and paste them in the input field, then try to select one word. In all cases above I just long tapped on one word and the highlight missed the word boundry as shown.
It does have to be a text field or input though. Any justified selectable text would reproduce the same behavior. I tried in both stable and master channels.
Here is my
flutter doctor
output:The text was updated successfully, but these errors were encountered: