new version of Enhanced phonetic reading (delayed descriptions)


William
 

David cm,

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




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



Noelia Ruiz
 

I think that problems mentioned in GitHub discusion and the fact that
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
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:

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





DaVid
 

We have very different points of view. In an ideal world, using the
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:

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


Noelia Ruiz
 

Hello:

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!

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









Rui Fontes
 

Thanks!

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!
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

On 7/26/2022 12:39 AM, DaVid wrote:
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.




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.