nvda
nvda copied to clipboard
nvaccess
Optional reporting of capitals while reading full text (not just characters)
Reported by Druify on 2013-06-16 19:30 The settings how capital letters are spoken only apply to current character announcement. Especially for proofreading, it is helpful if capital letters are also reported using functions like Speak Selection or Read from Here. Blocked by #4877 Blocking #914, #1712, #2122
Comment 1 by jteh on 2013-06-20 03:17 Practically speaking, I'm not sure how we could do this intuitively. If we say "cap word", how does the user know what this means; i.e. first letter capitalised or whole word capitalised? What if the word contains mixed upper and lower case? How do we handle beep or raise pitch for capitals?
In terms of technical implementation, doing this for beep and raise pitch would be extremely difficult.
Comment 3 by Druify (in reply to comment 1) on 2013-06-28 22:29 Replying to jteh:
If we say "cap word", how does the user know what this means; i.e. first letter capitalised or whole word capitalised?
Some screenreaders label them Cap words and ALL-CAP words and allow to set different voice pitches (or for the beeps, using different frequencies).
What if the word contains mixed upper and lower case?
This would be spoken similar to separated words, lige Loginscreen would be different to LogInScreen as (mixed-cap) log in screen. I'm not sure if it made sense to beep for such inner caps, but it'd be a start. However, I would not know how to signal the end of the Mixed-cap word, perhaps with a pause?
How do we handle beep or raise pitch for capitals?
Raise pitch option is possible depending on the used synthesizer, but it is possible already for spelling. So raise pitch practically would apply then to the complete word. Concerning beeps, the beeps for cap, all-cap and mixed-cap or the word (or even all of them) would be spoken and sounded before the concerned word.
In terms of technical implementation, doing this for beep and raise pitch would be extremely difficult.
I thought, the function for spelling letters would principally have to be applied to be considered for SayWord, SayLine, SayFromFocus etc. The procedure would be for each word to check: if cap, use cap-settings, if all-cap, use all-cap settings, if mixed-cap, use mixed-caps settings by splitting the word after each lower-case letter.
Comment 5 by jteh (in reply to comment 3) on 2014-10-29 23:06 Replying to Druify:
Raise pitch option is possible depending on the used synthesizer, but it is possible already for spelling. So raise pitch practically would apply then to the complete word.
I assume that relies on having different pitches for the different types of capitalisation (as you suggested earlier). Otherwise, you wouldn't be able ot distinguish them.
In terms of technical implementation, doing this for beep and raise pitch would be extremely difficult.
I thought, the function for spelling letters would principally have to be applied to be considered for SayWord, SayLine, SayFromFocus etc.
The code for doing this by character sends each character separately for the synth and waits for it to be spoken, so it's fairly easy to insert beeps. However, doing this for full reading would mean significant pauses after each chunk of text, which is probably undesirable. Even if it were okay, full reading currently just sends text to the synth; it doesn't have any ability to wait for certain portions of the speech and execute actions when that occurs. I have a rough idea of how this would be implemented, but it requires some pretty significant refactoring of our speech code.
Comment 6 by jteh on 2014-10-29 23:18 Changes: Changed title from "Announce capital letters optionally on any speech level" to "Optional reporting of capitals while reading full text (not just characters)"
I favor the idea of using a voice variant for title case, all caps, and mixed case. This might not be possible with just any synth, so perhaps it would be most practical to enable this feature only with eSpeak and possibly also with Eloquence as well, but eSpeak to start with at least. A slight pause for the variant to change I think would probably be acceptable, as those of us who have used similar features have probably become accustomed to that. This would make it much easier to proofread without a braille display for those who can't afford one. An increment of reading by character, and adding spell, word, and line would make this more flexible to user preference.
How about this? Instead of a voice variant, use pitch variation. A slightly higher pitch for words in proper case/first-letter caps, a slightly higher pitch for words in all-caps, and a slightly higher pitch still for mixed case words. Perhaps also the ability to configure how much to raise the pitch of the voice for each type of capitalization. This might, I think, make it possible to use such a feature with more synthesizers, as the pitch would be what changes instead of something so synth-specific as voice variant. I cite the example of Window-Eyes' capitalization alert feature for the screen voice as an example of how to make this work.
I invision the options for this as follows: a dialog box with a combobox or radio button group for when to indicate caps with the following options:
- say character.
- Also say word.
- Also say line.
- also say all.
- Off.
I imagine all these as cumulative, each option being added to the previous one until, with number 4, also say all, working along with all the previous options, so that caps are being indicated when reading by character, word, line, and say all.
An edit field for each type of capitalization, i.e., title case, all caps, and mixed case, indicating the pitch with a number or perhaps a percentage by which to raise or lower the pitch relative to the current/normal non-cap pitch. This seems more flexible than only allowing the pitch to be raised, so that users can specify a lower pitch for a given type of capitalization, in case someone wants words in, for instance, all caps, to be in a lower pitch.
the usual okay/cancel buttons.
Finally, a hotkey to toggle between the various capitalization alerts on the fly from outside the dialog, similar to the hotkey for keyboard echo.
There could also be options for beep versus saying cap/all caps/mixed case instead of or perhaps in addition to raising the pitch, the latter having the advantage of providing more thorough feedback. Indicating caps with beeping could be further fine-tuned with the ability to adjust the pitch of the beeps for each capitalization type, i.e., title case, all caps, and mixed case.
Just adding a suggestion to this proposed feature: A toggle of the entire function beyond announcing caps by character. Call it something like Enable Special Caps announcements, with options of on or off. If turned off, all the settings I've mentioned in previous comments could be disabled except for the traditional announcement of caps when navigating by character. If toggled on, then all the more advanced stuff could be enabled as set in the dialog I proposed in previous comments. This ability to hear caps and all caps when navigating by different units is the feature that keeps me using JAWS wherever possible. If this feature were added to NvDA, I would be comfortable with using NVDA fulltime for anything that doesn't require special scripting built into JAWS, which these days is only for my job as a medical language specialist having to do my work on a weird website. My problem is that my current authorization for JAWS doesn't support the latest Windows OS, so I use NVDA on my newer laptop but have to switch to a demo version of JAWS to do proofing of any serious writing, and I can't afford to upgrade JAWS. If I were a programmer, I would try to make this feature an add-on or even try and contribute core code to make this happen in NVDA. This is the single feature that is keeping me from using NVDA exclusively for non-work-specific use. I do a lot of serious writing outside my job and really wish I could just use NvDA to proof it. It's a pain to have to switch to JAWS, demo or no demo, to proofread for capitalization. In short, I am begging for this feature, and I don't think I am alone.
This was initially blocked prior to speech refactor. Is it still blocked? Just had someone mention this as one blocker for them to using NVDA so figured it was worth asking (and if no longer blocked, are we still happy for it to be P3?)
Closing issue #10822 which is a duplicate of this, but specifically that was a request for reading words in all caps with the same options (raised pitch, beeping or announcing "cap") as for individual letters (how to differentiate between a word with just the first letter capitalised and all caps in that case would need to be considered).
Hi.
Okay, this is how I'd imagine it can be implemented:
The three options for reporting capitals could be:
- Capital pitch change percentage (same)
- Speak cap for capitals
- Beep for capitals
Now, capital letter reporting would expand beyond just reading by character. The options would be:
Report capitals by:
- Characters
- Words (will have a lower tone for first letter cap, higher tone for mixed cap and even higher tone for all caps)
- Lines (including Say all) with the same rules applying for reporting capitals by word. These would all be checkboxes. Off does not need to be a setting, as capital reading can be turned off in NVDA by checking all three of the report capitals boxes, and these as well.
Now, there are two problems I see that can arise here. A user, like myself, who uses the pitch change to anounce capitals under normal circumstances would be left out of the configurability, and would hear a raised (or lowered) pitch depending on the state of capitals. However, this would require even more changes to the user interface to accomodate. Therefore, I think it should be left alone, with beeps and speech being the best alternatives. The second issue relates to how NVDA processes mixed cases by default, which seems to involve splitting the words in two. Therefore, I am not sure this can be detected.
Just curious as to whether there is any intention of actually implementing some paradigm for this? The issue has been open since June of 2013, six years, and the functionality exists in other screen readers. It keeps being asked about on the NVDA Group on Groups.io, again and again, and I can understand why.
If it's not going to be done, then that's one thing, close it. But looking at the amount of comment activity on this issue over those six years it definitely appears to be something that's still wanted, and, quite frankly, overdue.
@britechguy no reason for being so harsh. Just because an issue is open for a long time this does not mean that no one want to implement it. There are more than 2.000 issues out there and many of them are much more severe than this one. So be sure that if there will be time for this, one of the developers will certainly look into it. So if you don't mind, please add meaningful comments if you want to bring this discussion further.
Sorry, but if his is considered "harsh" then there's nothing more for me to add. When a ticket has been open for six years, with detailed conversations, it indicates either a complete lack of intention to make the change, in which case the honest thing to do is to close the ticket saying so, or that it is really low priority, in which case that should be stated.
Six years is way more than enough time to decide whether something as basic as this, which has long been a feature of at least one other major screen reader, is to be implemented or not. It just sits here.
The above is quite meaningful, whether you care to take it on board or not.
I think it is reasonable to ask about the progress of an issue, and very useful to know that users are asking about it in the user email group (or elsewhere). That's essentially what I did in this comment in March. This issue was previously blocked waiting on Speech Refactor. With the completion of that project, it is possible this issue is no longer blocked (I haven't looked at the code). It's usually hard to try to give a timeline for a specific issue, but knowing something is still being asked for does help with keeping it in mind.
I use Orca quite frequently and they have an interesting way of doing this. They have on their Voice Tab, an option for capitalization. One of the options is Icon. What happens when that is selected is that Orca clicks in the speech stream as it is reading where a capital would be without pausing. It doesn't give the precise point of the capital but I have found it extremely helpful. It helps me catch most cases, for example, a missing capital on a name or a missing capital on a word like "I" in the middle of a sentence. If you are listening to NVDA being read by Orca with this feature enabled, you actually hear a rapid group of clicks as that is spoken. You would actually be surprised how easy it is to notice a missing capital even in something like that. Just wanted to provide input because this is a technique that wasn't discussed yet and I use this feature every day for my job on my Linux machine.
I would also really like this feature to come to life. That would be just one more selling point for NVDA.
I could see Thomas's suggestion being useful when NVDA is set to "beep for capital", but how would it be implemented for "say cap before capitals" or "capital pitch change"?
Even then, if NVDA has passed a whole paragraph to the synthesizer, how do you time the beeps to coincide with capitals halfway through that paragraph?
I would just like to add my voice to those requesting some way to report capitalization while NVDA is reading lines sentences or paragraphs. I have to proofread carefully for work and I would rather do it by listening and not in Braille. I believe that just an audible signal, like the one for spelling errors, would be sufficient. this would alert the user that there are capitalizations in a word, and it would be up to the user to go back and check that word to find out if there is mixed case, or all caps, or what ever. I didn't know that NVDA had such a glaring deficiency until I actually needed it. I hope this is done soon!
There'a a workaround you can do using Nvda speech dictionaries and regular expressions that you can set up to make yourself a 'mention capitalization during continuous reading for proofreading purposes' feature.
See:
https://nvda.groups.io/g/nvda/message/102408
To add to @tararoys comment, another workaround was proposed in the NVDA Group on Groups.io in topic: Identifying Capital Letters
A DIC file was supplied by member Ricardo Leonarczyk, SayCap.dic, that snags capitalization for accented characters in the various romance languages in addition to English, and also takes acronyms into account. The download link for SayCap.dic is active as of the date of this writing, and since it was "placed in service" in 2019, it's probably as close to a permanent fixture as you'll get. The content of the file, for the record, is:
([A-ZÀ-Þ]{2,}) allcap \1 1 1 (\b[A-ZÀ-Þ]\b) cap \1 1 1 ([A-ZÀ-Þ])([a-zà-þ]) Cap \1\2 1 1 ([a-zà-þ])([A-ZÀ-Þ]\b) \1 cap\2 1 1
And yet another cycle on the NVDA Group on Groups.io discussing this. It comes up again, and again, and again. Given that other screen readers have implemented this, in one way or another, and it keeps being asked about over time, it really needs to get some love and attention.
NVDA Group Topic: How do I tell if a word is capitalized?
Clearly, the methods used by other screen readers have been found "adequate" by many users, and they've said so on various NVDA Group topics. Pick one, any one, to emulate and go for it.
In the comments, a developer said, " ...There are more than 2.000 issues out there and many of them are much more severe than this one..." One person's more severe issue may be another's less severe one. Narrator has this ability, I don't use JAWS much but I believe it has this ability. If NVDA is going to be properly useful in schools and professional work settings, this is an important feature. Punctuation can be announced. Hearing when capitals occur is just as important.
I think that a benchmark on how the other screen readers (Jaws, Narrator, Orca, VoiceOver) have integrated this feature and a detailed summary of it would help progress this issue.
For each summary, it would be interesting to know:
- which option is available and how they differ one from another
- if possible recordings illustrating each type of setting
- which option is default
- which option is popular (if known)
- also the differences (if any) when reading with sayAll, by line/word or by character, or when writing
- a copy of the paragraph (or a link) in the user manual or change log where this option is described
@britechguy would you have the background and the availability to do it?
@CyrilleB79
I agree that this information gathering would be very useful indeed, though I don't think it's strictly necessary only because virtually everyone involved has at least some experience with at least one screen reader other than NVDA. While the specific "hows" would be fascinating to know, we already know the basics.
If someone is capable of getting that information from across the spectrum of screen readers on multiple operating system platforms, that would be marvelous information to have if for no other reason than it can guide implementation decisions. But, alas, I definitely am not the person capable of collecting this, particularly for any non-Windows-based screen readers. I virtually never touch MacOS, iOS, or Linux and while I can make my way around VoiceOver as a clumsy user "in a pinch" I don't even have any iDevice or Mac available to me. I've never done a deep dive into TalkBack and whether/how it handles it even though I have an Android-powered device. I'm a very minimally skilled TalkBack user.
because virtually everyone involved has at least some experience with at least one screen reader other than NVDA.
Keep in mind that many people are using NVDA for a long time now, especially developers. So they may not be aware of features introduced in last years and also may not remember clearly how the other screen reader work. That's my case; even if I have been using Jaws during many years, I am totally unable to remember if capital letters were reported while reading text and how. And also if there were some setting to control it.
If someone is capable of getting that information from across the spectrum of screen readers on multiple operating system platforms, that would be marvelous information to have if for no other reason than it can guide implementation decisions. But, alas, I definitely am not the person capable of collecting this, particularly for any non-Windows-based screen readers. I virtually never touch MacOS, iOS, or Linux and while I can make my way around VoiceOver as a clumsy user "in a pinch" I don't even have any iDevice or Mac available to me. I've never done a deep dive into TalkBack and whether/how it handles it even though I have an Android-powered device. I'm a very minimally skilled TalkBack user.
OK, probably my request is a bit to much for a single person. But if you are able to answer the questions for one or two screen reader you know well (Jaws, Narrator?) that would be already valuable. And I had imagined that you know quite well at least one of them since you say that the feature is present for many years in them.
I have looked at Narrator (that I do not use myself). Below are my findings. Note that I have a French Windows so I do not know the exact words in Narrator's UI.
Narrator
- On characters (when typing or navigating with left/right arrows), "cap" is reported on cap letters, e.g. "cap a" for "A". And this does not seem to be controllable by any option.
- There is an option to define the mode how text with is caps is read. There are three possible values: do not report, raise pitch and say cap. It seems to impact the text when read normally, e.g. by line or with say all, not by character. The reporting is made for each word, word by word.
- when "say cap" is selected:
- "hello" is read "hello" as is
- "Hello" is read "cap hello"
- "hELLO" is read "mixed caps hello"
- "HELLO" is read "all caps hello"
- when raise pitch is selected:
- "Hello" is read with a pitch higher than "hello"
- "hELLO" with a pitch still higher than "Hello"
- "HELLO" with the highest pitch, still higher than "hELLO", even if quite near.
- when "say cap" is selected: