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
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
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
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
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
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.
2022-07-25 23:26 GMT-06:00, Noelia Ruiz <nrm1977@...>:
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: