Add exceptions for Braille unicode normalization

[fcnjd]

Steps to reproduce:

1. Set the input and output Braille table to German computer Braille (that's the one I'm familiar with)
2. Turn on Unicode normalization for Braille
3. Type in or read those superscript numbers: ¹, ², ³

Actual behavior:

The numbers get normalized to showing on the Braille display as ⠡⠀⠣⠀⠩

Expected behavior:

Since hte numbers have their corresponding Braille representation ⢁⠀⢃⠀⢉, they shouldn't get touched by the Unicode normalization.

NVDA logs, crash dumps and other attachments:

Not relevant here.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA 2024.4.1

Windows version:

Windows 10 22H2

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

Use any software to process text input.

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 other versions.

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

Yes, verified.

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

I don't think that can be relevant to Unicode normalization algorithm, so prefer not touching the registry.

[SaschaCowley]

This is actually expected behaviour. The unicode normalization algorithm does not know what the output device is, it simply converts "obscure" or "non-standard" characters to their "normalized" representation. In this case, the "normalized" representation of superscript numbers is baseline numbers, with superscript and subscript being presentational, so not really unicode's concern.

That being said, I can absolutely see how this is problematic. There is a workaround for speech (adding the symbols to symbols.dic). We should probably have a method of carving out similar exceptions for braille.

[fcnjd]

Thank you for your explanation, I see what you mean. Yes, I'd be very happy to see that workaround for Braille as well, because likely I'm not the only one working primarily with Braille and having speech off most of the time. In those situation such a change would lead to wrong numbers/calculations.

[Adriani90]

cc: @LeonarddeR

[LeonarddeR]

As @SaschaCowley said, this is indeed expected behavior, and one of the reasons why for braille,, unicode normalization is disabled.
Now the thing is that for German, these characters are properly defined, but it is not very unlikely that in other tables, the definition is missing in which case normalization can actually be of help.
I can see a reason why we want exclusions, but I'd rather see liblouis offer us a way to return us a list of characters that were undefined. Using the typeform system for that could probably be useful. We'd have to file a request for that upstream though.