Date
1 - 8 of 8
new version of Enhanced phonetic reading (delayed descriptions)
|
DaVid
Hi there!
I've updated this add-on, the only change is the added compatibility with NVDA version 2022.2, and removed the beta version. It's currently stable, since a long time ago no one has reported problems with this add-on. It's the same as previously known as delayed descriptions, with some internal differences, and with the functionality to always keep the character description active if you toggle it on. The last functionality mentioned, cannot be activated permanently, it is useful for people with deafness. Although the delayed character description feature is being implemented in NVDA core, I have a feeling that the way it is being implemented will generate a lot of inconvenience to the users due to the method used. Since it will present many differences according to the synthesizer we are using and the speed at which we set each synthesizer. Which would be a problem especially for those of us who have the habit of having several profiles with different speeds, or who adjust the speed according to the situation. That's why I've opted to keep giving it maintenance. But this is another topic. You will have the opportunity to test the feature implemented in the NVDA core, when it reaches the alpha versions, with all synthesizers that you are using. here is the download link for the latest version of enhanced phonetic reading. https://github.com/davidacm/EnhancedPhoneticReading/releases/download/1.1.3/EnhancedPhoneticReading-1.1.3.nvda-addon P.S. If you want to know more about how this feature is being implemented in NVDA core, you can read more in this PR and why I disagree with that aproach. https://github.com/nvaccess/nvda/pull/13550 Regards, David.
|
|
|
|
Akash Kakkar
Thanks David for the update
toggle quoted messageShow quoted text
On 7/26/2022 12:39 AM, DaVid wrote:
Hi there!
|
|
|
|
Rui Fontes
Thanks!
toggle quoted messageShow quoted text
I feel the same regarding the NVDA implementation... In spite I am using the NVDA Alpha versions, I keep using your add-on and not the native implementation... Best regards, Rui Fontes NVDA portuguese team Às 20:09 de 25/07/2022, DaVid escreveu:
Hi there!
|
|
|
|
Noelia Ruiz
Hello:
toggle quoted messageShow quoted text
For a better understanding of the reasons of NVDA's core implementation, it's an open discussion without replies. Explanations made there by Sean (NV Access) convinced me. Of course this doesn't mean that the add-on is not useful. I think it can coexist with NVDA core feature, and add-ons may serve this purpose. Here's the discussion and I'd like to see good reasons to prove that what it's mentioned there is not valid, if it can be done: https://github.com/nvaccess/nvda/discussions/13886 Cheers 2022-07-25 21:38 GMT+02:00, Rui Fontes <rui.fontes@...>:
Thanks!
|
|
|
|
DaVid
We have very different points of view. In an ideal world, using the
toggle quoted messageShow quoted text
ability of the synthesizer would be the right thing to do, but unfortunately, most synthesizer developers never considered making the pauses sent by break commands accurate. It is very noticeable especially in one core and sapi 5, but even espeak has this problem. in my IBMTTS driver, we tried to solve this problem, although it was not completely solved but it is corrected a little bit. Unfortunately not everybody can use IBMTTS, or wouldn't like to use it, and there are many synths in the world. I don't know what other synthesizers are available in other languages such as Japanese, Chinese, etc... There are many old synthesizers, that are still used by the users and those synths will never be fixed in the accuracy of the pauses. But the point is that there is no standard for that parameter, or even some synthesizers don't implement it at all. It will be quite problematic in this last case. It is even worse, when it was decided to make the "time delay" parameter a generalized setting. Because if I adjust it to my liking for sapi5 and switch to Espeak for example, I will have to do the setting again. Or when I change the speed for some reason, I usually change the speed very often according to my current task or environment. I haven't seen something like this happen in other screen readers that implement this feature in the core. The pause is always the same regardless of which voice is used or the current speed adjusted in the screen reader. Regardless of whether or not CallLater is used, a timer should be used instead of relying on the synthesizer used by the user. I think that the precision in the delay between the read character and the character description is very important for the usability of a screen reader. All my arguments against the current implementation were already given and there is not much to add about it. Users who are unaware of this drawback with synthesizers will probably ask questions in their respective forums. Regards, David CM 2022-07-25 23:26 GMT-06:00, Noelia Ruiz <nrm1977@...>:
Hello:
|
|
|
|
Noelia Ruiz
I think that problems mentioned in GitHub discusion and the fact that
toggle quoted messageShow quoted text
synthesizers don't have good support for breakCommand are both true and not incompatible statements. So I understand that in NVDA core they use breakCommand and that you have released this add-on. Also I think that the GitHub discusion about timers maybe useful to see if they can be implemented in a different way in NVDA. 2022-07-26 8:17 GMT+02:00, DaVid <dhf360@...>:
We have very different points of view. In an ideal world, using the
|
|
|
|
Cyrille
Hello
If the BreakCommand is inaccurate for synthesizers included in NVDA (OneCore, SAPI5, eSpeak), this issue should be tracked. It has no sense to keep an half-working feature in NVDA and then say "I do not use this feature because it's not working" without reporting it formally. Of course, this matter of facts has been signalled in the PR's discussion. But if the persons who have experienced this lack of accuracy could open a GitHub issue against NVDA with a full example (reproducible and measurable), this would really help fixing the BreakCommand issue, at least for synthesizers included in NVDA. If nothing can be done to fix it due to technical limitation or external blocking issue, maybe NVAccess will change its mind on this topic. In any case, the add-on deserves its existence while the BreakCommand is inaccurate in NVDA or in other third-party add-on, which may be a very long time. Cheers, Cyrille
|
|
|
|
William
David cm,
toggle quoted messageShow quoted text
Happy to see that your addon finally reach stable version. Once again, thank you for your great job. DaVid 於 26/7/2022 03:09 寫道:
Hi there!
|
|
|