• FAIL: Translation comments check. Translation comments missing or unexpectedly included. See build log for more information.
• PASS: License check.
• PASS: Unit tests.
• FAIL: Lint check. See test results and lint artifacts for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/chmns0s7oaqn6jru/artifacts/output/nvda_snapshot_pr16864-32933,a40a1c3f.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.3,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 13.6,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 18.7,
  FINISH_END 0.2

See test results for failed build of commit a40a1c3f2a

This is a very interesting piece of work, thank you for this Sascha.
I think it would be really nice if there was a way to show the tags only when the caret is explicitely moved via cursor routing keys by the user? e.g.

1. Read a line of text on the braille display without showing tags
2. Press the cursor routing key on a specific character > NVDA shows formatting tags around the word / and the characters in case there are multiple formatting styles within a word

This could be combined with the touch sensible braille displays where you could press on a character twice or press and hold, and the formating tag appears for a short period of time afterwards.

I am not sure whether braille display vendors are working on different behaviors of cursor routing (e.g. press multiple times, press and hold, double press and hold etc. which could give you more information about the word / character / selected text).
cc: @FelixGruetzmacher I think this has huge potential and might open up many use cases.

Thank you for this useful pr.

Couple of notes:

Write for example line:

This is a test line.

Bold "This is".

Go to start of line, and select it with shift+end.

Selection starts from "T" and ends in the end of line thus covering also end tag of bold. But start tag is shown as not selected.

Empty document again, then:

• ctrl-b to start bold
• then write "test." without quotes
• press ctrl-b to finish bold and
• then press spacebar.

Sometimes start tag is not shown in braille. I tested with word 2019, and "use UIA" is default in nvda advanced settings.

I think that one additional mode could be indicate all attributes with dots 7 and 8. This could also contain links as well. Advantage would be that additional information would not require extra space. If user would be interested whatkinds of additional information is in question, he/she could switch to "tag mode" or use "report formatting information for the text under this braille cell" gesture. So adding gesture for changin "indicating font attribute mode" would be useful.

I do also prefer dots 7 and 8 for the same reason that @burmancomp has described and a gesture for additional information when needed.

@Adriani90 said:

I think it would be really nice if there was a way to show the tags only when the caret is explicitely moved via cursor routing keys by the user?

Adding this behaviour would be out of scope for this PR. Could you open a new issue and reference this PR (or just mention the new behaviour)?

@burmancomp said:

Write for example line:

This is a test line.

Bold "This is".

Go to start of line, and select it with shift+end.

Selection starts from "T" and ends in the end of line thus covering also end tag of bold. But start tag is shown as not selected.

This is not unique to this work. For instance: (keyboard shortcuts likely vary if you're not using Word in English)

1. Open a word document, and enter "This is a link, and this is too".
2. Select "This is a test", press Ctrl+K to create a link, and enter "example.com" as the destination.
3. Repeat step 2 for "this is too".
4. Select all with Ctrl+A, and the first "lnk" will not be selected, but the second will.

This is because of the way we show selection in braille, and would require changes that are out of scope for this issue. If you like, you can search to see if there's an issue open for this, and, if not, open one.

• PASS: Translation comments check.
• PASS: License check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/n33juib4xph2tg8p/artifacts/output/nvda_snapshot_pr16864-33021,504374c1.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.1,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 12.6,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 18.3,
  FINISH_END 0.2

See test results for failed build of commit 504374c1ae

This is not unique to this work. For instance: (keyboard shortcuts likely vary if you're not using Word in English)

1. Open a word document, and enter "This is a link, and this is too".

2. Select "This is a test", press `Ctrl+K` to create a link, and enter "example.com" as the destination.

3. Repeat step 2 for "this is too".

4. Select all with `Ctrl+A`, and the first "lnk" will not be selected, but the second will.

This is because of the way we show selection in braille, and would require changes that are out of scope for this issue. If you like, you can search to see if there's an issue open for this, and, if not, open one.

Yes, you are right.

As to my other note maybe you would like to consider it.

@burmancomp said:

Sometimes start tag is not shown in braille. I tested with word 2019, and "use UIA" is default in nvda advanced settings.

I am unable to reproduce this, could you please give more concrete reproduction steps?

@burmancomp, @Jykke67, using dots 7 and/or 8 to indicate formatting is a feature that has already been requested. It is technically more difficult to implement, but is something we're looking in to.

@burmancomp said:

Sometimes start tag is not shown in braille. I tested with word 2019, and "use UIA" is default in nvda advanced settings.

I am unable to reproduce this, could you please give more concrete reproduction steps?

Let's try with this:

• empty word document
• write text "link 1. link 2."
• select "link 1."
• make link with ctrl+k.
  Now both start and end tags are shown for "link 1."

then:

• select "link 2."
• make link with ctrl+k.

Only start tag is shown for "link 2.".

Then:

• press spacebar.
  Now end tag for "link 2." appears in braille.

I have windows 11 with word 2019 (not 365).

@burmancomp, this is exactly the same behaviour as we get in speech:
Speech output: "link underlined Link one. not underlined link underlined Link 2."
If you insert a space after the link, however:
Speech output: "link underlined Link one. not underlined link underlined Link 2. not underlined"
This happens because we're comparing the previous and current formatting to show changes. Since there's no text at the end of that string that isn't underlined, we don't know to show the end underline marker. As far as I know, there's no easy way to fix this.
As this issue is not unique to this work, could you open a new issue for it?