All symbols are not sent to sapi 5 tts

[burmancomp]

Steps to reproduce:

At least mikropuhe (sapi 5 tts used in Finland) does not receive all characters. This can be detected through mikropuhe own interpretation system.

Ensure that "\n" and "\r" are sent to tts through punctuation/symbol pronunciation dialog.

Actual behavior:

Mikropuhe never receives these symbols.

Expected behavior:

It should receive them.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

current alpha

Windows version:

w10 22h2 (should apply to w11)

Name and version of other software in use when reproducing the issue:

atl least mikropuhe 5.1 (I guess mikropuhe 5.4 and likely other sapi 5 synthesizers as well)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

If NVDA add-ons are disabled, is your problem still occurring?

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

[burmancomp]

cc: @irrah68

[zstanecic]

@burmancomp
Have you tried to force send these symbols through the NVDA punctuation dialog?

[burmancomp]

Yes. I have set level to character and "send actual symbol to synthesizer" to always.

[zstanecic]

By the way, is Mikropuhe Unicode compliant?

[irrah68]

By the way, is Mikropuhe Unicode compliant?

Not fully. It has some kind of Unicode support but it doesn't work or atleast I don't know how to get most out of it.

But the problem with line break characters is something which seems to concern only NVDA at the moment. There are many other programs which communicate directly with Sapi and they work without problems; a pause can be heard when thera line breaks. I manage to add pauses to NVDA:s speech when using Mikropuhe speech syntesizer, but it is another story.

[SaschaCowley]

@burmancomp, @irrah68, what is the use-case here? What is the expected behaviour?

[irrah68]

The expected behaviour is that the line break characters \n and \r are sent directly to the speech synthesizer, which can then handle them, for example add some pauses between lines. This depends on how configurable the speech synthesizer is.

It seems that \n and \r are sent to the user dictionaries, voice dictionaries, but are not sent from there to the synthesizer.

[burmancomp]

When "send actual symbol to synthesizer" is set to "always", this should happen every time for every symbol. If all symbols are not allowed to be sent to synthesizer then that alternative should not be selectable for those symbols.

[burmancomp]

It is good that user can select if given symbol is sent to synthesizer. It is important that user can rely that this also happens. If for some reason, for example sapi5 parts of microsoft block symbols, that behavior should be documented, and it should not be possible to select for these symbols that they can be sent to synthesizer.

I think this issue should be triaged.

[burmancomp]

@SaschaCowley may I ask why this is not triaged.

[SaschaCowley]

@burmancomp we were unclear as to the use-case, so could not triage. Unfortunately this issue slipped our notice when processing new issues. We will make sure to triage it when we next triage issues

[burmancomp]

Thanks @SaschaCowley

[gerald-hartig]

The "ask" on this is unclear and touches more generally on how NVDA works. Converting this to a discussion.

[burmancomp]

Sorry @gerald-hartig but could you explain this conversion to discussion? What is unclear? What makes it "big thing" that all symbols should be sent to TTS because UI already shows that this should happen.

[CyrilleB79]

@gerald-hartig wrote:

The "ask" on this is unclear and touches more generally on how NVDA works.

@irrah68 wrote in #17533 (comment):

The expected behaviour is that the line break characters \n and \r are sent directly to the speech synthesizer, which can then handle them, for example add some pauses between lines. This depends on how configurable the speech synthesizer is.

If I understand correctly, some synth are able to add a pause where there are \r\n and thus, and thus people ask not to remove them from the strings passed to the synth. The use case and the request seem quite clear.

Also @burmancomp wrote in #17533 (comment):

It is good that user can select if given symbol is sent to synthesizer. It is important that user can rely that this also happens. If for some reason, for example sapi5 parts of microsoft block symbols, that behavior should be documented, and it should not be possible to select for these symbols that they can be sent to synthesizer. (Editor's note: in the dialogue of symbols)

This request is also understandable and completely valid IMO.

To summarize, the initial request seems valid and precise enough to be discussed in an issue. If the change request is not accepted due to strong software architecture limitations, at least the fact that it should be documented and the request on the UX of the symbol dialog should be accepted as valid (triaged). @gerald-hartig would you reconsider this triage action and accept reopening an issue for this?