-
-
Notifications
You must be signed in to change notification settings - Fork 634
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
Separate the reporting of superscripts and subscripts from the report font attributes setting #10919
Conversation
I think text position is ambiguous, as alignment also says something about the position of the text. |
Fixed. |
See test results for failed build of commit 45f7a89490 |
SOrry for me not being explicit enough I think that it is ok to call the option reportScript, as that's way shorter than reportSubScriptsAndSUperScripts. At first glance, you could leave the label as is, may be @feerrenrut has suggestions as what wording is used to cover both sub and superscript Could you also add a config spec update that:
|
I prefer "report superscripts and subscripts" to "report script". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @codeofdusk
Hi, I'm afraid this introduced a regression: a KeyError exception is raised when NVDA+F is pressed to obtain formatting information. Thanks. |
Traceback:
This is seen when pressing NVDA+F from browse mode documents. Thanks. |
Fixes #10931 Follow on from #10919 The "report formatting script" (NVDA+f) was causing an error because the `reportSuperscriptsAndSubscripts` key was missing from the `formatConfig` dictionary used as a config section created in ` _reportFormattingHelper`. Updated the generation of this dictionary so this error is unlikely to be encountered again. Instead, now the risk is that any format option separated in the future my not be reported by the "report formatting script" when it should be. Some superscript/subscript reporting was not separated. To fix this the superscript/subscript fetching has been separated in more situations (PowerPoint, UIA).
Is it possible to exclude the reporting of baseline when pressing quick navigation key in browse mode? When I enabe superscripts and subscripts, NVDA always reports "base line" when I press quick navigation keys (i.e. b for buttons in the commenting area). This is quite annoying on some websites. This should be only reported when NVDA detects a mathematical content or if this is part of a text block while navigating with reading commands. |
Most likely, open a separate issue and hopefully someone will take it. |
In the Powerpoint appModule, the incorrect config key was used. Looking up reportSuperscriptAndSubscript (instead of the correct reportSuperscriptsAndSubscripts) resulted in an error, making certain functions unusable. Config option introduced in: "Separate the reporting of superscripts and subscripts from the report font attributes setting #10919" Regression introduced with: #10932 Fixes #11094.
Hi, |
In IAccessible edit field such as WordPad, enabling "Superscript and subscript" reporting in Document formatting settings was not enough to have them reported. It was also required to have Font attributes reporting enabled. This is due to a forgotten part of the code when reporting of superscript/subscript has been separated from reporting of the other attributes in #10919. Description of how this pull request fixes the issue: Added the missing 'if' statement
Link to issue number:
Related to #3727.
Summary of the issue:
The reporting of superscript and subscript is controlled by the "report font attributes" setting (which is far too verbose for reading of mathematical/scientific documents using the
<sup>
/<sub>
HTML tags).Description of how this pull request fixes the issue:
Adds a new setting, "report superscripts and subscripts", which controls whether superscripted/subscripted text is read.
Testing performed:
With all possible combinations of "report superscripts and subscripts" and "report font attributes", tested that HTML documents in Chrome using the
<sup>
tag read correctly and that no non-selected formatting information is reported.Known issues with pull request:
I'm not sure how to make this work in Braille – does NVDA even present superscripts/subscripts to Braille displays?
Change log entry:
== Changes ==