Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA version alpha-31360,dd44cbb7: In the "Regular expression for text paragraph navigation" field, NVDA does not announce all the characters #16288

Closed
paulber19 opened this issue Mar 10, 2024 · 6 comments · Fixed by #16299
Milestone

Comments

@paulber19
Copy link

Steps to reproduce:

Actual behavior:

  • Open "NVDA settings",
  • go to "Advanded" cateNngory and check "I understand that changing these settings may cause NVDA to function incorrectly. check box.
  • pess "shift+tab" to reach "Regular expression for text paragraph navigation" field.
  • press "end" and press "leftArrow" key some times.

After the third time,characters are not announced by NVDA.

[.…]{1,3}["”»)]?([\d+])*(?=[\r\n  ]|$)|[?!]|[.!?:;])

Expected behavior:

NVDA must announce the characters

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

NVDA portable

NVDA version:

NVDA version alpha-31360,dd44cbb7:

Windows version:

Windows 10

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

None

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.

No

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

Yes

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

Yes

@Adriani90
Copy link
Collaborator

Is the Window maximized?
We also need a log file at debug logging level.

@CyrilleB79
Copy link
Collaborator

@paulber19, could you modify the title of this issue to provide it in English?
(not for me but for other people)

@wmhn1872265132
Copy link
Contributor

This may be caused by some full-width symbols not being defined in the corresponding language's symbol file, and the speech engine not recognizing the symbol.

@paulber19 paulber19 changed the title NVDA version alpha-31360,dd44cbb7: Dans le champs "Regular expression for text paragraph navigation ", NVDA n'annonce pas tous les caractères. NVDA version alpha-31360,dd44cbb7: In the "Regular expression for text paragraph navigation" field, NVDA does not announce all the characters Mar 11, 2024
@paulber19
Copy link
Author

paulber19 commented Mar 11, 2024 via email

@seanbudd seanbudd added this to the 2024.2 milestone Mar 11, 2024
@CyrilleB79
Copy link
Collaborator

There are many characters that are not spoken by OneCore or Eloquence. In the first place, it would be the job of the synth to report them. On the contrary, eSpeak reports something.

NVDA takes into account that not all synth correctly report symbols and provide the symbols.dic file / symbols dialog to overcome this problem.

Of course, we can just add the missing symbols in the symbol file.

The use case of reading a regexp in the advanced settings panel is clearly not the most significant one. There are probably other open tickets asking to add more symbols in the symbol file.

The question is:
To what extent should the symbol file compensate for the problems of the synths?
Is there a risk if we add too much symbols in this file, e.g. performance issue?

@seanbudd, NV Access' opinion on this (if any) would be appreciated.

If this issue is implemented updating the symbol file, care should be taken to not break Chinese text reading at any level of punctuation. Probably preserve=all should be used.

The question is:

@seanbudd
Copy link
Member

I don't think there is a risk to adding too many symbols to this file, I think we should set sensible defaults for as many symbols as deemed appropriate.
I think since one main purpose of the symbol file is to compensate for synthesizer behaviour, adding more symbols where appropriate makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants