Braille highlight crash bug

[NSoiffer]

The following MathML causes a string alignment error in the braille highlighting code:

thread 'main' (28060) panicked at src\braille.rs:124:38:
byte index 2 is not a char boundary; it is inside '🍎' (bytes 0..4) of `🍎🍐⠘⠆⠀⣍⠭

This is for Nemeth. It does not happen with UEB.

<math>
  <mtable>
    <mtr><mtd><mrow><mtext>🍎</mtext><msup><mtext>🍐</mtext><mn>2</mn></msup></mrow></mtd></mtr>
    <mtr><mtd><mi>x</mi></mtd></mtr>
  </mtable>
</math>

This is narrowed down from a larger example. It seems to require the two lines of a table to be triggered (which likely inserts some things at the start of the line).

Note: some efficiency hacks assume the number of bytes/char in some cases and that is probably the problem.

Update: the problem is that the emoji are unknown to MathCAT and they are flowing through into the braille instead of being converted to braille dots. So the real problem is what to do with characters that are not part of the Unicode YAML files. This potentially affects all braille codes.

[NSoiffer]

Looking at what NVDA's braille display does with undefined characters, and getting feedback from @mwhapples that explains the NVDA output/display, the output's 8 dot ascii braille uses:

• '\xhhhh' if it is a 16 bit char
• '\yhhhhhh' if it is a 24 bit chr
• '\yhhhhhhhh' if it is a 32 bit chr

The \ is represented as dots "1267".

Perhaps given NVDA's behavior and the potential for speech to help explain what it is, the above format is what MathCAT should generate for characters that don't have a braille code.

[mwhapples]

For speech you may want to look into unicode libraries which can get the character name. Not sure for Rust but in Java Character.getName(int codepoint) is a possible candidate.