Link to issue number:

Closes #18722 
Reverts 021bcd8

Summary of the issue:

The code that split a string at character boundaries discarded characters like \u0301 when such a character was the only character in a string.

Description of user facing changes:

When unicode normalization is on, navigating by character will again correctly announce characters like acute (\u0301)

Description of developer facing changes:

• NVDAHelper local calculateCharacterBoundaries now needs an offsets array that is textLength + 1 in size, rather than only the text length. This is to store the end offset of the last character.
• This reverts 021bcd8, therefore we don't pass additional extraneous alphanumeric characters to uniscribe to make it happy.

Description of development approach:

While debugging this issue, I found several issues in NVDAHelper local textUtils _getLogAttrArray function that is the base of the several calculation functions:

1. The buffer passed to ScriptItemize was too small when a string only contained one character. The buffer should have space for at least two SCRIPT_ITEM structures in size. This is my hypothesis about the necessity of 021bcd8, namely the addition of two alphanumeric characters passed to the uniscribe methods. While there are no exactly known str to reproduce the issue behind 021bcd8, I tried several combinations of shorter and longer strings without alpha numeric characters, and I couldn't reproduce any of the behavior described in it after my changes to the c++ code. Therefore I reverted 021bcd8, as there is enough time to test this in Alpha thoroughly.
2. Calculation of character offsets would never set the end offset when requesting the offsets of the last character in the string, since the end offset calculation starts at offset + 1 and offset + 1 is equal to textLength.
3. Failed calls of ScriptItemize and ScriptBreak were never logged. ScriptItemize definitely failed when passing a string with only one character in it because the expected buffer was to small.

Testing strategy:

• Unit tests
• System tests
• STR from Combining diacritics are not read when typing/navigating if Unicode normalization is enabled #18722

Known issues with pull request:

The call of ScriptBreak seems wrong when a string contains two or more items generated by ScriptItemize. This seems so because the iCharLength variable is never limited to the length of the item, but rather extended to the length of the string every time. However, if we reset iCharLength and call ScriptBreak for only the text that belongs to the current item, we get word navigation behavior that diverges from the one in Notepad. Therefore I left this as is and documented it in code in case someone stumbles upon this again in the future.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

@coderabbitai summary