search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

a configuration option to pass punctuation symbols to the synthesizer #1597

Closed nvaccessAuto closed 8 years ago

nvaccessAuto commented 13 years ago

Reported by aleksey_s on 2011-06-21 20:45 After introducing of new punctuation framework, a few users complained that they like the old behavior when NVDA passed punctuation symbols to the synthesizer every time. For example, they are used to hear an end-of-sentence intonation when reading file name and its extension (to distinguish one from another), an intonation of colom when reading time etc. After 2011.2 beta release, the number of users complaining was even grown. Therefore, I suggest implementing an option which, if active, will force NVDA to ignore the punctuation preserving flagif it is set. In this mode NVDA will expand labels of punctuation it knows within the scope of current punctuation level and bypass other to the synth without cutting it from the text.

Classifying as major since I hear more and more complains about this one from the Russian community. Blocking #4621

nvaccessAuto commented 13 years ago

Comment 1 by fatma.mehanna on 2011-06-21 22:25 yes that's true. the arabic community also started to complain. they want nvda to read what is written on the screen whatever it is. now, what happens is if we changed the interface into arabic, every punctuation mark or symbol pronounced in arabic even if it is preceded by an english text.

nvaccessAuto commented 13 years ago

Comment 2 by jteh on 2011-06-21 22:49 If we implement this, users will then go back to complaining about two things (which were common complaints before the new framework):

  1. Most synths choose to pronounce certain symbols as words when encountered, rather than just changing inflection or pausing. Therefore, the synth will pronounce certain symbols even though the user has punctuation set to none.
  2. If we speak symbols normally when moving by character, they may be pronounced differently than the pronunciation used by the synth (as per the first point). This is extremely inconsistent and inconsistency is bad. For these reasons, if we do implement this, we should just have an option for synthesiser controlled punctuation. Moving by character would then expect the synth to pronounce the characters. Any symbols not pronounced by the synth would just say nothing. At least this way, it's very clear, consistent and easy for the user to understand: we always rely on the synth to handle punctuation. If the synth doesn't handle it, nothing handles it.
nvaccessAuto commented 13 years ago

Comment 3 by jteh (in reply to comment 1) on 2011-06-21 22:52 Replying to fatma.mehanna:

now, what happens is if we changed the interface into arabic, every punctuation mark or symbol pronounced in arabic even if it is preceded by an english text.

When moving by character (and reading normal text with speak punctuation enabled), this would have been the same before the new framework was implemented. This is really a different issue. Proper handling of this requires language detection of the text.

nvaccessAuto commented 13 years ago

Comment 5 by jteh on 2011-06-21 22:53 Btw, you can solve the issue with "." and ":" yourself by setting preserve to norep. That's the whole point of that option.

nvaccessAuto commented 13 years ago

Comment 6 by Ahiiron (in reply to comment 2) on 2011-06-22 00:03 Replying to jteh:

For these reasons, if we do implement this, we should just have an option for synthesiser controlled punctuation. Moving by character would then expect the synth to pronounce the characters. Any symbols not pronounced by the synth would just say nothing. At least this way, it's very clear, consistent and easy for the user to understand: we always rely on the synth to handle punctuation. If the synth doesn't handle it, nothing handles it.

+1

nvaccessAuto commented 13 years ago

Comment 7 by jteh on 2011-06-22 02:40 95c24a35cccf58eba874fa822e5c3f4e09d391b8 fixes the pronunciation of times, currency and negative numbers. This covers the complaints from most users. There may be other specific rules that we need to add.

If you want "." to be preserved, you can edit your user symbols, setting preserve to either all or norep depending on your preferences. The way this is handled differs across synthesisers, so customisation is not unacceptable here.

I think an option like this is too confusing for most users to understand and creates inconsistency. Changes: Added labels: wontfix State: closed

nvaccessAuto commented 13 years ago

Comment 8 by aleksey_s (in reply to comment 7) on 2011-06-23 05:16 Replying to jteh:

If you want "." to be preserved, you can edit your user symbols, setting preserve to either all or norep depending on your preferences.

I'd argue that it is impossible to access this from the GUI so is unacceptable option for most users.

nvaccessAuto commented 13 years ago

Comment 9 by briang1 on 2011-06-23 16:05 Well, I note just before reading this, that someone has posted a query to the support list about editing the symbols.dic file directly, so my thought is maybe you need an advanced options in the gui of the symbols editor for these extra parameters at some point in the future.

nvaccessAuto commented 13 years ago

Comment 10 by jteh (in reply to comment 8) on 2011-06-28 01:57 Replying to aleksey_s:

If you want "." to be preserved, you can edit your user symbols, setting preserve to either all or norep depending on your preferences.

I'd argue that it is impossible to access this from the GUI so is unacceptable option for most users.

I'd counter-argue that most users wouldn't understand the option even if it was available in the GUI. Preservation of symbols will mean nothing to most users.