Fix ZeroDivisionError when pitch is 0 announcing 'cap'

[seanbudd]

Link to issue number:

Fixes #10940

Summary of the issue:

NVDA fails to announce "cap" for capital letters when synthesizer pitch is set to 0. This is because of a division by 0 error when scaling the pitch change for "cap".

Description of user facing changes

NVDA successfully announces "cap" for capital letters as if synthesizer pitch was set to 1.

Description of development approach

To fix this, use a value of 1 instead of 0 when calculating the pitch for announcing "cap".

Testing strategy:

Manually test STR with notepad

1. Enable "Say 'cap' before capitals" in Speech
2. Ensure that "capital pitch change percentage" is set to value different than 0
3. Set synthesizer pitch to 0
4. Try to read character by character "aA"

Known issues with pull request:

None

Change log entries:

Bug fixes

- Fix bug where NVDA failed to announce "cap" for capitals when synthesizer pitch was set to 0. (#10940)

Code Review Checklist:

• [x] Pull Request description:
  • description is up to date
  • change log entries
• [x] Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• [x] API is compatible with existing add-ons.
• [x] Documentation:
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• [x] UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests. See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/5okgr9qapywor73c/artifacts/output/nvda_snapshot_pr13921-25921,691b6d03.exe

See test results for failed build of commit 691b6d037d

[feerrenrut]

May also be worth considering: #9811

[seanbudd]

Using this approach, eSpeak fails to change pitch for 'cap', as eSpeak scales the pitch by multiplying by the base pitch of 0. An issue/PR to eSpeak is required to inform them that when pitch is set to 0, pitch change commands fail to scale the pitch correctly.

An alternative approach is to make NVDA use the range 1-100 instead of 0-100. This was previously blocked by changing the wx.Slider to the range 1-100, i.e. only 100 intervals not 101.

[feerrenrut]

Next action: report issue to espeak.

[seanbudd]

Using this approach, eSpeak fails to change pitch for 'cap', as eSpeak scales the pitch by multiplying by the base pitch of 0. An issue/PR to eSpeak is required to inform them that when pitch is set to 0, pitch change commands fail to scale the pitch correctly. Next action: report issue to espeak.

It turns out this bug was with NVDA. The eSpeak synth driver code to handle prosody commands did not handle the offset attribute, only the multiplier attribute. The only known usage of offset is for capPitchChange. There also seems to be incorrect support on all other synthesizers. This PR will instead aim to fix the PitchCommand for all synthesizers.

[seanbudd]

Related bugs: https://github.com/nvaccess/nvda/issues/10214 https://github.com/nvaccess/nvda/issues/7514 https://github.com/nvaccess/nvda/issues/2195

[seanbudd]

I'm going to look into dropping the offset attribute from all BaseProsodyCommands as it is not supported correctly in general

[codeofdusk]

I'm going to look into dropping the offset attribute from all BaseProsodyCommands as it is not supported correctly in general

Given that 2024.1 is an API breaking release, might now be a good time to do this (or, ideally, to fix the broekn behaviour)? @seanbudd @jcsteh

[rmcpantoja]

Hi, I would like to take this opportunity to add that, in NVDA builds with Python 3.7, especially the stable versions, the division by zero errors are caused by an internal library, and it's not an error specifically with any of the core scripts or anything in the source code. I think it's something close to the pydecimal.py library. The strangest thing is that in the alpha versions that were built with Python 3.7 at the time, this error did not occur, and everything worked fine. I have had to experience this with the num2words add-on, and testing the num2words package locally this error doesn't occur and makes a conversion without errors. At the moment the add-on works with the latest alpha built with Python 3.11, including the decimal numbers that cause the division error in stable versions. So, I think it has to do with the build process of the artifacts.

[seanbudd]

@codeofdusk - this can be fixed in a way which temporarily preserves backwards compatibility