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

arabic diacritics are not being read in some applications #4664

Closed
nvaccessAuto opened this issue Dec 3, 2014 · 8 comments
Closed

arabic diacritics are not being read in some applications #4664

nvaccessAuto opened this issue Dec 3, 2014 · 8 comments
Labels
bug close/cantfix component/i18n existing localisations or internationalisation

Comments

@nvaccessAuto
Copy link

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.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-12-04 00:52
The application chooses this behaviour; NVDA doesn't change the behaviour of the cursor keys. I don't know much about the Arabic script, but from what I've read, this arguably makes some sense, since as I understand it, the diacritics aren't a necessary part of the text; they just aid in it's interpretation. Therefore, it might not be useful to have the cursor touch all of them. Note that you can still use the NVDA review cursor to read the text without skipping the diacritics, so as far as an NVDA user is concerned, they're still accessible.
Changes:
Added labels: cantfix
State: closed

@nvaccessAuto
Copy link
Author

Comment 2 by fatma.mehanna on 2014-12-05 12:55
ok, can you open a ticket for us against libreoffice?
as we dont currently have an account or dont know where to report the problem
this problem effects arabic, pharsi, and may be hebrew.
thanks.

@nvaccessAuto
Copy link
Author

Comment 3 by bhavyashah on 2014-12-05 14:05
Hi,
Though I don't know what diacritics are, from what I read and understand this issue, it occurs with Hindi as well, in Notepad.
For example: if I type the word पालिका and read the typed word character by character in Notepad, the results are:
first right arrow = प
second right arrow = ल
third right arrow = क
Are we talking about the same issue here?
If so, then please report this issue as well to the concerned person.
Thanks a lot

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2014-12-06 02:08
As I said in comment:1, this behaviour is possibly intentional. I certainly doubt you'll be able to get it changed in the Windows Edit control (which is what Notepad uses). As for LibreOffice, you can try filing a bug against LibreOffice. I'm not willing to do this myself, since this isn't really related to screen reader accessibility (especially given that you can use the review cursor to see these characters) and I don't have the language expertise to make a solid argument as to why this should be different. Feel free to cc me on any bugs you file; I can at least try to make sure it gets some attention if the case is strong enough.

@nvaccessAuto
Copy link
Author

Comment 5 by mohammed on 2014-12-06 12:15
very interesting! is there a way to edit while using the review cursor? editing is necessary to proof read since diacritics are necessary for the meaning.

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
Changes:
Changed title from "arabic diacretics are not being read in some applications" to "arabic diacritics are not being read in some applications"

@nvaccessAuto
Copy link
Author

Comment 6 by jteh (in reply to comment 5) on 2014-12-06 13:46
Replying to mohammed:

is there a way to edit while using the review cursor?

Not directly, but you can route the caret to the review position (desktop: NVDA+shift+numpadMinus).

editing is necessary to proof read since diacritics are necessary for the meaning.

I don't quite follow what you mean here. If you mean being able to delete them, backspace still works to delete them.

Libra office should really fix their implementation because it's a productivity suite

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.

@nvaccessAuto
Copy link
Author

Comment 7 by mohammed on 2014-12-06 14:15
It's certainly a bug because diacritics are important to the meaning. while most modern Arabic is not written with diacritics, it's still necessary especially in academic setting. Libre Office is a productivity suite, and people may choose it to write their academic essays. editing with the review cursor sounds inconvenient and annoying at best. before you want to backspace to delete a diacritic, you'd want to put your cursor in the right spot.

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).

@nvaccessAuto nvaccessAuto added close/cantfix bug component/i18n existing localisations or internationalisation labels Nov 10, 2015
@khaledhosny
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug close/cantfix component/i18n existing localisations or internationalisation
Projects
None yet
Development

No branches or pull requests

2 participants