Skip to content
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

Keys which produce a compound character spoken as separate typed characters #1428

Open
nvaccessAuto opened this issue Mar 23, 2011 · 10 comments
Labels
bug component/i18n existing localisations or internationalisation p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2011-03-23 22:05
Some languages contain characters which do not have a single unicode character representation. Instead, pressing such a key produces a sequence of multiple unicode characters. This sequence looks like a single character and behaves like a single character in some respects; i.e. left/right arrow keys move the cursor past the entire compound character. However, the input actually contains several unicode characters.

Str:

  1. Install the Tamil keyboard layout.
  2. Open a Wordpad document, switch to the Tamil keyboard layout and enable speak typed characters.
  3. Press "shift+.".
  4. Expected: NVDA should speak one character. (Tamil: "sri")
  5. Actual: NVDA individually speaks the four characters ("ஸ்ரீ") composing this compound character. (Tamil: "sa otru ra ii")

Other letters in Tamil like this:
||= Letter =||= Key =||
|| த்ர || shift+6 ||
|| க்ஷ || shift+7 ||
|| ஷ்ர || shift+8 ||
|| ஞ்ச || shift+ஜ ||
|| ந்த || shift+த ||
|| ஃப || shift+ப ||

I haven't checked this yet, but I'm pretty sure Windows actually sends separate WM_CHAR messages for these characters; that is the only way it could work, since WM_CHAR only handles one character. Unless there's something I don't know about which indicates whether a character is a compound character and when it ends, this is going to be difficult to fix. We can't use WM_KEYUP to determine when a character ends, as this would mean we'd have to wait for the key to be released to have it announced. Using a timer would incur delay in speaking of typed characters, which is unacceptable.
Blocking #4487

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2011-03-24 08:05
Not that I know a lot about this, but has anyone tried narrator to see what it does for such characters?

@nvaccessAuto
Copy link
Author

Comment 2 by pvagner on 2011-03-24 10:10
I don't seem to be able to install tamil keyboard layout on my windows xp.
Are there some extra steps needed?

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2011-03-24 19:41
Check the "Install files for complex script and right-to-left languages (including Thai)" checkbox.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2014-09-25 23:08
See also #2791, which will affect the same characters in some (but not all) applications when navigating by character.

@LeonarddeR
Copy link
Collaborator

CC @jcsteh

@jcsteh
Copy link
Contributor

jcsteh commented Jul 18, 2017

P4 for now because even though it makes speak typed characters useless for some languages, we haven't had any complaints in many years with those communities, so we're not sure how much this actually matters to them for whatever reason. CC @dineshkaushal for any thoughts.

@jcsteh jcsteh added the p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jul 18, 2017
@Adriani90
Copy link
Collaborator

@dineshkaushal your thoughts on this are very appreciated, thanks.

@Adriani90
Copy link
Collaborator

@michaelDCurran is this solved by #10550? cc: @jcsteh since you created this issue years ago.

@Adriani90
Copy link
Collaborator

If there are such characters in chinese as well, maybe @cary-rowen and @hwf1324 can you have a look and test if this issue is still relevant?

@jcsteh
Copy link
Contributor

jcsteh commented Mar 24, 2024

#10550 is unlikely to fix this because it relates to navigating by character, whereas this relates to typed characters, which are handled differently. I suspect this bug still exists, though it doesn't seem like anyone cares any more?

Chinese input is handled differently - it has an input method editor rather than keys mapping directly to characters - so it is handled by a very specific part of NVDA and probably doesn't suffer from this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug component/i18n existing localisations or internationalisation p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Development

No branches or pull requests

4 participants