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.