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

Links in Word aren't displayed with the lnk indicator in braille #6780

Closed
dkager opened this issue Jan 22, 2017 · 5 comments
Closed

Links in Word aren't displayed with the lnk indicator in braille #6780

dkager opened this issue Jan 22, 2017 · 5 comments
Labels
p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Milestone

Comments

@dkager
Copy link
Collaborator

dkager commented Jan 22, 2017

STR:

  1. Open Word, tested with Word 2016.
  2. Type "This is something to click on."
  3. Select the word "click", right-click on it, choose Hyperlink... and make it a link.

Speech reads:
This is something to link click out of link on.
Braille shows:
This is something to click on.
Expected:
Braille somehow shows the link, e.g. with the "lnk" indicator.

@dkager
Copy link
Collaborator Author

dkager commented Jan 22, 2017

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

We should probably also work something out for comments/revisions.

@jcsteh jcsteh added the p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jan 22, 2017
@jcsteh
Copy link
Contributor

jcsteh commented Jan 22, 2017

P2 because this is important info that isn't available to braille only users.

@dkager commented on 23 Jan. 2017, 5:19 am AEST:

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

isAtStart isn't useful here, since that's to ensure we don't present info in the middle of the line that should only be presented at the start. However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

We should probably also work something out for comments/revisions.

Indeed, though I don't consider that quite as high priority (though still important) and we should address it separately.

@dkager
Copy link
Collaborator Author

dkager commented Jan 23, 2017

However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

It looks like this only applies if you have some text selected. Then you have three chunks: text before and after selection, and the selection itself. But that implies there can be multiple "link start" commands for the same text. Is that true?

@jcsteh
Copy link
Contributor

jcsteh commented Jan 25, 2017 via email

@dkager
Copy link
Collaborator Author

dkager commented Jan 25, 2017

I'm going with a full cache like is used for speech, because that looks the most extensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Development

No branches or pull requests

3 participants