-
-
Notifications
You must be signed in to change notification settings - Fork 623
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
arabic diacritics are not being read in some applications #4664
Comments
|
Comment 1 by jteh on 2014-12-04 00:52 |
|
Comment 2 by fatma.mehanna on 2014-12-05 12:55 |
|
Comment 3 by bhavyashah on 2014-12-05 14:05 |
|
Comment 4 by jteh on 2014-12-06 02:08 |
|
Comment 5 by mohammed on 2014-12-06 12:15 at the end of the day, such bug is something you can live with because there are other application that would do the job. Libra office should really fix their implementation because it's a productivity suite |
|
Comment 6 by jteh (in reply to comment 5) on 2014-12-06 13:46
Not directly, but you can route the caret to the review position (desktop: NVDA+shift+numpadMinus).
I don't quite follow what you mean here. If you mean being able to delete them, backspace still works to delete them.
You see this as a bug, but as I said in comment:1, there might be arguments as to why it might be intentional. Can you explain why those arguments aren't valid? You'll definitely need to be able to justify this to LibreOffice developers if you want this fixed there. |
|
Comment 7 by mohammed on 2014-12-06 14:15 let me illustrate how diacritics are important to the meaning: consider the word كتبو if you write it like this "كضتضبض" then it's the past tense of write (wrote), if you write it like this "كُتِبَ" then it's the passive form (has been written), while if it's written like this "كُتُب" then it becomes a noun (books). |
|
This issue was reported against LibreOffice recently (https://bugs.documentfoundation.org/show_bug.cgi?id=100854), so I’ll just try to clarify some points here. Most applications use grapheme clusters (http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries) as the unit for cursor movement, since grapheme clusters is what the user perceives as a “letter”. A base character plus any number of combining marks is considered a grapheme cluster and so a cursor movement will skip them as the whole. A similar issue happens with many Indic scripts (like the example in #4664 (comment) above) where a number of code points is considered as one grapheme cluster. Changing the behavior of LibreOffice (and tens of other applications) is very unlikely since this is the expected behavior by most users, also allowing the cursor movement to treat combining marks separately is visually confusing since the marks will have zero advance width so moving the cursor after them will not provide any visual feedback. I’m not sure how screen readers should handle this, though, but the problem is not limited to Arabic (it affects any text where there are multi-character point grapheme clusters) and is not limited to LibreOffice either. |
Reported by fatma.mehanna on 2014-12-03 18:49
Hi,
as it clear from the summary, nvda reads the arabic diacretics, which can be considered as the vowels, in some applications while it doesn't read them in others.
for example, if i write an arabic word with diacretics in wordpad, notepad++, or microsoft word, the diacs can be read when i navigate with right/left arrow to move between letters.
if i type the same word in notepad or libera office, and move with the arrow keys, nvda ignores these diacs and just move between the letters as if i didn't write any diacs.
a word like فَاطِمَةً is an example.
try to copy the word above in a notepad text file and navigate between the letters. what you will notice nvda will just move between the letters and ignores the diacs.
thanks.
The text was updated successfully, but these errors were encountered: