Hexadecimal Unicode Characters Braille Tables

Also known as HUC Braille Tables
Simplified, worldwide unified 8- and 6-dot mapping for the hexadecimal value of Unicode characters

Table of contents

Explanation of Unicode characters in plain language

Introduction to Unicode:

Unicode is a worldwide encoding standard to save text.
Unicode contains letters, digits, musical symbols, emojis and so on.
Every Unicode character has its own Unicode code point.
There are 1,114,112 code points.
The Unicode standard 12.0 (March 2019) defines 137,993 characters.

Unicode version:

The Unicode standard is updated regularly.
Every update adds more characters to the Unicode standard.
The HUC Braille Tables needs no updates, after a new Unicode standard was released.
Because all 1,114,122 code points are already defined in the HUC Braille Tables.

Hexadecimal value:

The code points are represented in hexadecimal values.
A hexadecimal value contains the digits 0, 1 to 9 and the letters A to F.
Four to six hexadecimal values stand behind "U+".
U+0030 is the code point for the character "Digit Zero" ("0").
The range of the code points goes from U+0000 to U+10FFFF.

Encoding formats:

There are three common encoding formats for Unicode: UTF-8, UTF-16 and UTF-32.
UTF-8 is used by lots of websites around the world.
UTF-16 is often used by operating systems and applications.
And UTF-32 needs the most space to save a Unicode character.

Surrogates in UTF-16:

The code points for UTF-16 go from U+0000 to U+FFFF.
Unicode characters between U+10000 and U+10FFFF are split into two parts in UTF-16.
These two parts are called high and low surrogates.
Therefore these surrogate characters are only replacement characters.
NVDA 2019.1 only supports UTF-16 for the braille output.

Therefore two characters are displayed instead of one on a braille display.
Unicode characters between U+0000 and U+FFFF are still displayed with one character.
Or with even more characters, because this depends on the used braille table.

Definition for 8- and 6-dot in plain language

Introduction to braille tables:

Different braille tables are used around the world.
And there are uncontracted and contracted braille tables too.
But all these braille tables only define a few hundreds characters respectively words.
The German 8-dot braille table doesn't contain emojis.
The "Grinning Face" Unicode character is an emoji.

The problem:

This emoji is displayed as '\xd83d''\xde00' in NVDA 2019.1.
But other braille tables just display ⠀ or a question mark.
The braille character ⠀ has no haptic dot.
So this character is identical to a space.
The first representation needs quite a lot of space on a braille display.

And the second one uses the same braille character for all undefined characters.
Both systems aren't really good.

The solution:

The Hexadecimal Unicode Characters Braille Tables simplifies and shortens undefined characters.
But the HUC Braille Tables don't change existing definitions.
The HUC Braille Tables only extend all existing braille tables.
Thus the above mentioned Unicode character is now displayed as ⣥⣆⡉⣥⢂⣺ in 8-dot braille.
And in 6-dot braille ⠿⠆⠛⠆⠿⠂⠼⠞ is displayed in NVDA 2019.1.

Finally you save space and can read the Unicode character faster.

Prefix and suffix braille characters:

Every previous undefined character starts with ⣥, ⣭, ⣽, ⣵ or with ⠿.
⣥ stands for Unicode characters between U+0000 and U+FFFF.
This so-called prefix character is often used in 8-dot braille.
⣭, ⣽ and ⣵ stand for Unicode characters between U+10000 and U+10FFFF.
⠿ is the prefix character for all previous undefined characters in 6-dot braille.

As 6-dot braille is principally used for printing, the fourth character is always displayed as ⠄, ⠠ or as ⠤.
And if ⠤ is on the fourth position, ⠄ or ⠤ is following as a second so-called suffix character.
The hexadecimal value of a Unicode code point is combined to save space.
Two hexadecimal values are displayed within one single 8-dot braille character.
In the first two 6-dot braille characters three hexadecimal values are displayed.

The second hexadecimal value is split here between the two braille characters.
The fourth and the fifth 6-dot braille character are always a combination of a hexadecimal value and the suffix character.

Converting hexadecimal values into braille:

The hexadecimal values are defined in the HUC Braille Tables as follows:
0 = ⠚, 1 = ⠁, 2 = ⠃, 3 = ⠉, 4 = ⠙, 5 = ⠑, 6 = ⠋, 7 = ⠛
8 = ⠓, 9 = ⠊, A = ⠈, B = ⠘, C = ⠒, D = ⠂, E = ⠐, F = ⠀
⣥⣆⡉⣥⢂⣺ as well as ⠿⠆⠛⠆⠿⠂⠼⠞ stand both for the Unicode characters U+D83D and U+DE00.
These two Unicode characters are a surrogate pair because of UTF-16.

Search for the character:

Search on the web for both Unicode code points together.
If you can't find the Unicode character directly, you should convert the two code points into UTF-32.
Visit the UTF-16 surrogates page to do this.
This surrogate conversion isn't required for characters between U+0000 and U+FFFF.
And also not any longer, after NVDA supports UTF-32.

After that happened, the above mentioned character will then been displayed as ⣭⡤⣺ or as ⠿⠤⠵⠺.
Last tip: Create a text file with some Unicode characters and their names to find them faster.

Usage

  • First of all it should be noted that the HUC Braille Tables don't change any existing definitions or replace any existing braille tables, they only extend all existing braille tables. Furthermore the HUC Braille Tables don't contain any contractions and they work independently of language and region the same, because they are only displaying the code point of a Unicode character. How Unicode characters are used and spoken in the different languages and regions isn't part of the HUC Braille Tables.
  • Depending on the braille table you are using, undefined Unicode characters are always shown with the same braille character or with their hexadecimal value such as '\x0030'. And if the end application doesn't support UTF-32, which is the case with NVDA 2019.1, only five "Grinning Face" characters (U+1F600) need 80 braille characters for completely displaying them all on a braille display.
  • By using the HUC8 Braille Tables in NVDA 2019.1 the amount of necessary braille characters for these five Unicode characters is reduced from 80 to 30. And after NVDA also supports UTF-32, the amount of necessary braille characters is reduced to only 15. So you save 62.5 respectively 81.25 % space.
  • Well, but as ⣥⣺⢽⣥⣺⡟⣥⣺⢃⣥⣺⣣⣥⣺⠵⣥⣺⠋⣥⣺⠋⣥⣺⠋⣥⣺⡋ instead of ⡙⠗⠄⠀⡎⠕⠕⠕⠍ for "Dr. Sooom" makes absolutely no sense, the HUC Braille Tables are only designed to replace the previous mentioned behaviors with a solution, which needs less space. Thus only the kind of displaying Unicode characters, which aren't defined in the primary braille table, are changed to the new simplified and shortened behavior.
  • So if you have quite a lot of C-, Canto-, Mando- and J-pop as well as hundreds of video game and anime soundtracks from Japan on your hard drive, displaying their titles needs quite a lot of space on a braille display. And to set the braille character ⠀ (U-2800, dot 0) for all undefined characters, which is the case in the Liblouis braille table "fr-bfu-comp8.utb" (version 3.9.0), isn't a suitable solution too, if you want to select a title without using TTS. That means that you should be able to recognize them only on the braille display, completely without any additional sound feedback, which only would affect the listening experience in a negative way.
  • Thus the main benefit of the HUC Braille Tables is that you can read more at the same time without having to scroll and scroll and scroll the braille display all the time. And in the end this always means that through this you are able to recognize the hexadecimal values much faster because you only have to read three to five instead of eight braille characters for one single Unicode character.
  • Please note that the HUC Braille Tables don't omit any significant information, they only reduce unnecessary stuff to the absolute possible minimum.
  • Furthermore the HUC Braille Tables already contain all 1,114,112 Unicode code points (U+0000 to U+10FFFF). Therefore it isn't necessary to update the HUC Braille Tables after the Unicode Consortium released a new Unicode standard, because all code points are already defined. So after the Unicode Consortium assigned more Unicode characters to code points, you are already able to read them all at day one.
  • And also note that the HUC8 Braille Tables are designed primary for displaying on a braille display and the HUC6 Braille Tables primary for printing on paper. Therefore ⠀ (U+2800, dot 0) as a suffix character in the HUC6 Braille Tables isn't allowed at the fourth position.

Definition for 8-dot

Prefix braille characters:

  • The prefix character must stand in front of every single Unicode character. To avoid confusion, grouping of two or more unseparated, consecutive Unicode characters, such as ⣥⣺⣩⣥⣺⣩ to ⣥⣺⣩⣺⣩, isn't allowed.
  • ⣥ = code points between U+0000 and U+FFFF
    Code point: U+28E5; Braille dots: 13678
    Defines the first 65,536 Unicode code points.
    The prefix character is a combination of the letters u and c.
  • ⣭ = code points between U+10000 and U+1FFFF
    Code point: U+28ED; Braille dots: 134678
    Defines the second 65,536 Unicode code points.
    The prefix character is a combination of the letters u and c and the digit 1.
  • ⣽ = code points between U+20000 and U+2FFFF
    Code point: U+28FD; Braille dots: 1345678
    Defines the third 65,536 Unicode code points.
    The prefix character is a combination of the letters u and c and the digit 2.
  • ⣵ = code points between U+30000 and U+10FFFF
    Code point: U+28F5; Braille dots: 135678
    Defines the other 917,504 Unicode code points.
    The prefix character is a combination of the letters u, e and c.
    And from this point three braille characters are needed to define a Unicode code point correctly.
    U+30000 will be changed to U+030000 before converting into braille.
    In Unicode 12.0 (March 2019) only 337 characters are assigned in these planes.

List for all 17 Unicode planes:

  • ⣥ = code points between U+0000 and U+FFFF
  • ⣭ = code points between U+10000 and U+1FFFF
  • ⣽ = code points between U+20000 and U+2FFFF
  • ⣵⠾ = code points between U+30000 and U+3FFFF
  • ⣵⢾ = code points between U+40000 and U+4FFFF
  • ⣵⢞ = code points between U+50000 and U+5FFFF
  • ⣵⡾ = code points between U+60000 and U+6FFFF
  • ⣵⣾ = code points between U+70000 and U+7FFFF
  • ⣵⣞ = code points between U+80000 and U+8FFFF
  • ⣵⡺ = code points between U+90000 and U+9FFFF
  • ⣵⠺ = code points between U+A0000 and U+AFFFF
  • ⣵⢺ = code points between U+B0000 and U+BFFFF
  • ⣵⣚ = code points between U+C0000 and U+CFFFF
  • ⣵⡚ = code points between U+D0000 and U+DFFFF
  • ⣵⢚ = code points between U+E0000 and U+EFFFF
  • ⣵⠚ = code points between U+F0000 and U+FFFFF
  • ⣵⣡ = code points between U+100000 and U+10FFFF

Converting hexadecimal values into braille:

0 = ⠚, 1 = ⠁, 2 = ⠃, 3 = ⠉, 4 = ⠙, 5 = ⠑, 6 = ⠋, 7 = ⠛
8 = ⠓, 9 = ⠊, A = ⠈, B = ⠘, C = ⠒, D = ⠂, E = ⠐, F = ⠀

Combining hexadecimal values:

00 = ⣺, 01 = ⠞, 10 = ⣡, EF = ⠐, FE = ⢀, FF = ⠀

Examples for 8-dot

Unicode name Character Code point Hexadecimal display HUC8 display
Digit Zero 0 U+0030 '\x0030' ⣥⣺⣩
2 × Digit Zero 00 U+0030U+0030 '\x0030''\x0030' ⣥⣺⣩⣥⣺⣩
Music Sharp Sign U+266F '\x266f' ⣥⡧⠋
Braille Pattern Dots-12 U+2803 '\x2803' ⣥⣇⠾
Musical Symbol G Clef 𝄞 U+1D11E '\y1d11e' / '\xd834''\xdd1e' ⣭⠆⢁ / ⣥⣆⢭⣥⡂⢁
Grinning Face 😀 U+1F600 '\y1f600' / '\xd83d''\xde00' ⣭⡤⣺ / ⣥⣆⡉⣥⢂⣺

Notes: The end application must support UTF-32, otherwise all Unicode characters between U+10000 and U+10FFFF are displayed with their UTF-16 surrogates. Please visit the UTF-16 surrogates page to get a complete list of all UTF-16 surrogate pairs with their UTF-32 equivalents.

Definition for 6-dot

Prefix and suffix braille characters:

  • The prefix character must stand in front of every single Unicode character. To avoid confusion, grouping of two or more unseparated, consecutive Unicode characters, such as ⠿⠺⠛⠞⠿⠺⠛⠞ to ⠿⠺⠛⠞⠺⠛⠞, isn't allowed.
  • The very last hexadecimal value stands always in the area of the dots 1245 in the fourth braille character. The dots 3 and 6 define the suffix character, which is also always at the fourth position. In other words: The fourth braille character is always a combination of a hexadecimal value and the suffix character. And it's exactly the same way for the fifth braille character for the Unicode code points between U+20000 and U+10FFFF.
  • The two non-breaking spaces (" ") between the prefix and the suffix character are only placeholders for three hexadecimal values. The fourth last hexadecimal value is located in the area of the dots 1245 in the first braille character, the third last one is split between the first and the second braille character (dots 36 and 14) and the second last one is located in the area of the dots 2356 in the second braille character. The last two hexadecimal values of a Unicode code point are the most important one. Therefore they shouldn't be split between two 6-dot braille characters.
  • And to avoid misunderstanding, ⠀ (U+2800, braille dot 0) isn't allowed as a suffix character.
  • ⠿  ⠄ = code points between U+0000 and U+FFFF
    Code points: U+283F and U+2804; Braille dots: 123456 and 3
    Defines the first 65,536 Unicode code points.
  • ⠿  ⠠ = code points between U+10000 and U+1FFFF
    Code points: U+283F and U+2820; Braille dots: 123456 and 6
    Defines the second 65,536 Unicode code points.
  • ⠿  ⠤⠇ = code points between U+20000 and U+2FFFF
    Code points: U+283F, U+2824 and U+2807; Braille dots: 123456, 36 and 123
    Defines the third 65,536 Unicode code points.
    And from this point four braille characters are needed to define a Unicode code point correctly.
    In Unicode 12.0 (March 2019) 60,859 characters are assigned in the plane U+2xxxx and 337 more in the planes higher than U+30000.
    The first hexadecimal value for U+2xxxx must stand behind the fourth braille character in the area of the dots 1245 to define the Unicode plane correctly.
    And for the Unicode code points from U+100000 to U+10FFFF the braille character ⠥ (U+2825, braille dots 136) is used to define this Unicode plane.

List for all 17 Unicode planes:

  • ⠿  ⠄ = code points between U+0000 and U+FFFF
  • ⠿  ⠠ = code points between U+10000 and U+1FFFF
  • ⠿  ⠤⠇ = code points between U+20000 and U+2FFFF
  • ⠿  ⠤⠍ = code points between U+30000 and U+3FFFF
  • ⠿  ⠤⠝ = code points between U+40000 and U+4FFFF
  • ⠿  ⠤⠕ = code points between U+50000 and U+5FFFF
  • ⠿  ⠤⠏ = code points between U+60000 and U+6FFFF
  • ⠿  ⠤⠟ = code points between U+70000 and U+7FFFF
  • ⠿  ⠤⠗ = code points between U+80000 and U+8FFFF
  • ⠿  ⠤⠎ = code points between U+90000 and U+9FFFF
  • ⠿  ⠤⠌ = code points between U+A0000 and U+AFFFF
  • ⠿  ⠤⠜ = code points between U+B0000 and U+BFFFF
  • ⠿  ⠤⠖ = code points between U+C0000 and U+CFFFF
  • ⠿  ⠤⠆ = code points between U+D0000 and U+DFFFF
  • ⠿  ⠤⠔ = code points between U+E0000 and U+EFFFF
  • ⠿  ⠤⠄ = code points between U+F0000 and U+FFFFF
  • ⠿  ⠤⠥ = code points between U+100000 and U+10FFFF

Converting hexadecimal values into braille:

0 = ⠚, 1 = ⠁, 2 = ⠃, 3 = ⠉, 4 = ⠙, 5 = ⠑, 6 = ⠋, 7 = ⠛
8 = ⠓, 9 = ⠊, A = ⠈, B = ⠘, C = ⠒, D = ⠂, E = ⠐, F = ⠀

Combining hexadecimal values:

0000 = ⠺⠽⠚, 0001 = ⠺⠽⠁, 0010 = ⠺⠋⠚, 0100 = ⠞⠴⠚
1000 = ⠡⠽⠚, FFEF = ⠀⠠⠀, FFFE = ⠀⠀⠐, FFFF = ⠀⠀⠀

Examples for 6-dot

Unicode name Character Code point Hexadecimal display HUC6 display
Digit Zero 0 U+0030 '\x0030' ⠿⠺⠛⠞
2 × Digit Zero 00 U+0030U+0030 '\x0030''\x0030' ⠿⠺⠛⠞⠿⠺⠛⠞
Music Sharp Sign U+266F '\x266f' ⠿⠧⠗⠄
Braille Pattern Dots-12 U+2803 '\x2803' ⠿⠇⠽⠍
Musical Symbol G Clef 𝄞 U+1D11E '\y1d11e' / '\xd834''\xdd1e' ⠿⠆⠂⠰ / ⠿⠆⠛⠝⠿⠂⠃⠔
Grinning Face 😀 U+1F600 '\y1f600' / '\xd83d''\xde00' ⠿⠤⠵⠺ / ⠿⠆⠛⠆⠿⠂⠼⠞

Notes: The end application must support UTF-32, otherwise all Unicode characters between U+10000 and U+10FFFF are displayed with their UTF-16 surrogates. Please visit the UTF-16 surrogates page to get a complete list of all UTF-16 surrogate pairs with their UTF-32 equivalents.

Downloads

  • HUC8 Braille Tables – 2019-03-01 (1.58 MB, 7z)
    SHA-256: ec60e5cd6cae8302870fa422361562febb5d6a0a2c05de869ba545cb5294d65f
    License: © 2019 Daniel Mayr (alias Dr. Sooom), LGPL 2.1+
    Note: This version is prepared to be included into Liblouis. It isn't already part of it.
  • HUC6 Braille Tables – 2019-05-01 (1.82 MB, 7z)
    SHA-256: df943a007c759b7d16dd11effd5a89a7c8ec5f52f093af8a2794c444b1caf274
    License: © 2019 Daniel Mayr (alias Dr. Sooom), LGPL 2.1+
    Note: This version is prepared to be included into Liblouis. It isn't already part of it.
  • More downloadable files can be found on the downloads page at Daniel Mayr.at (only available in German).

Installation instructions for NVDA 2019.1 (installed version, UTF-16)

Note: To perform the following instructions administrator privileges are required.
  1. Download the latest version of the HUC8 or the HUC6 Braille Tables and open them with 7-Zip.
  2. As NVDA 2019.1 doesn't support UTF-32, only the following files have to be copied from the 7z archive:
    • "huc8-utf16.tbl" and "huc8-u+0000-u+ffff.tbi" or
    • "huc6-utf16.tbl" and "huc6-u+0000-u+ffff.tbi"
  3. Select these two files and press F5 to copy them.
  4. As NVDA is installed by default in "C:\Program Files (x86)\NVDA\", please choose the Windows Desktop or any other folder, where administrator privileges aren't required for writing, to copy these two files temporary to another folder.
  5. Then select these just copied files on your Desktop or in your previous chosen destination folder via the Windows Explorer and move them to the folder "louis\tables\" in the folder, where NVDA is installed.
    Note: If NVDA is installed in "C:\Program Files (x86)\NVDA\", you need administrator privileges to proceed this operation.
  6. After you have found the name of the Braille Table, which you want to extend with the HUC8 or with the HUC6 Braille Tables, open that file with Notepad++ (or with any other source code editor) and insert "include huc8-utf16.tbl" or "include huc6-utf16.tbl" followed by a line break at the end of the file.
    Note: The very last line must be blank, otherwise the braille output fails. And depending on the NVDA program folder you need administrator privileges here again.
  7. Save the file, restart NVDA and the HUC Braille Tables should work. If not, then please take a look at the FAQ.

Installation instructions for NVDA 2019.1 (portable version, UTF-16)

Note: To perform the following instructions administrator privileges normally shouldn't be required.
  1. Download the latest version of the HUC8 or the HUC6 Braille Tables and open them with 7-Zip.
  2. As NVDA 2019.1 doesn't support UTF-32, only the following files have to be copied from the 7z archive:
    • "huc8-utf16.tbl" and "huc8-u+0000-u+ffff.tbi" or
    • "huc6-utf16.tbl" and "huc6-u+0000-u+ffff.tbi"
  3. Select these two files and press F5 to copy them.
  4. As NVDA is installed as a portable application, you only have to choose the folder "louis\tables\" in the NVDA program folder as the destination folder.
  5. After you have found the name of the Braille Table, which you want to extend with the HUC8 or with the HUC6 Braille Tables, open that file with Notepad++ (or with any other source code editor) and insert "include huc8-utf16.tbl" or "include huc6-utf16.tbl" followed by a line break at the end of the file.
    Note: The very last line must be blank, otherwise the braille output fails.
  6. Save the file, restart NVDA and the HUC Braille Tables should work. If not, then please take a look at the FAQ.

Uninstallation instructions for NVDA 2019.1 (installed/portable version)

Note: To perform the following instructions administrator privileges are required depending where and how NVDA is installed.
  1. After you have found the name of the Braille Table, which you don't want to extend with the HUC8 or with the HUC6 Braille Tables any longer, open that file with Notepad++ and insert a hash ("#") directly in front of the "include huc…".
    Note: The very last line must remain blank, otherwise the braille output fails.
  2. Save the file, restart NVDA and the HUC Braille Tables shouldn't work any longer.

Frequently asked questions (FAQ)

Who is the founder/author/creator of the HUC Braille Tables? [⣺]

Exclusively me, Daniel Mayr alias Dr. Sooom. Please read the announcement regarding the first release of the HUC Braille Tables website and the HUC8 Braille Tables at Daniel Mayr.at (partly in German and partly in English) for more details.

And who is the author/creator of this website respectively of the HUC Braille Tables documentation on it? [⠞]

Also me, Daniel Mayr alias Dr. Sooom. Well, to be exactly I need some help from another person to create the favicon. And I'm also the author of the English and German parts of this website respectively of the HUC Braille Tables documentation. If you are currently reading this text in another language than English or German, please take a look at the footer to see the translator. Please read the announcement regarding the first release of the HUC Braille Tables website and the HUC8 Braille Tables at Daniel Mayr.at (partly in German and partly in English) for more details.

How does the favicon look like? [⡞]

It's a 16 × 16 pixels small, very dark gray squared with the very light gray braille character ⣥ (U+28E5, braille dots 13678), which is horizontal and vertical centered in this squared. The exact background color is #333333 and the color of the braille character is #DDDDDD.

Are the HUC Braille Tables and the documentations on this website available at no charge? [⠾]

Yes, because the HUC Braille Tables are licensed under LGPL 2.1+ and the documentations under (cc) by-sa. For further information please take a look at the header section of each tbl and tbi file by opening them with Notepad++ or any other source code editor, as well as at the imprint and privacy policy page (only available in German).

And why are the HUC Braille Tables and the documentations on this website available at no charge? [⡁]

Because in my opinion reading is an absolute basic need, especially at the beginning of the 21st century. Therefore everyone around the globe should have the same access for reading, no matter if they are reading visual with their eyes or haptic with their fingers. And no, speech output via TTS synthesizers has nothing to do with reading, because speech output is a linear information channel. But if you are able to read, you are able to jump immediately between characters within a long word or between lines without having to interact with the media to get the information you want. Okay, most of the braille displays out there only contain one single line, therefore you have to press a button to switch the line, but this isn't valid for braille content printed on paper. An last but not least 10,00 EUR for both HUC Braille Tables might not be quite a lot of money in Austria, in the USA or in Japan, but in other countries it's already too expensive for specific groups. So it would be extremely unfair to exclude these groups from reading because of too less capital.

Are the HUC Braille Tables already a standard? [⢾]

In March 2019, the answer is no. But it could become one in the future.

What is the correct pronunciation for "HUC"? [⢞]

In English it's "hook" and in German "Huck". The vowel "u" is spoken shortly. The pronunciation in other languages should be as close as possible to the English or to the German one.

Why are the both suffix braille characters for the last Unicode plane in the HUC6 Braille Tables defined as ⠤⠥ and not as ⠤⠾? [⢁]

Because ⠤⠥ is easier to read instead of ⠤⠾. Furthermore you can see ⠤⠥ as a combination of its HUC8 pendant with the regular suffix braille character ("⠄"). And as the last Unicode plane starts with the digit 1, it makes more sense to put this value in the area of the dots 1245.

What are the differences between the online and the offline version of the documentation? [⡾]

The offline version of the html file doesn't contain the favicon, the Google Analytics code, the section "Downloads" and the list of available languages. But the complete content of the css file is included in those offline html files, otherwise the stylesheet wouldn't work. And as that would be the same with all relative URLs, they all are converted into absolute URLs in the offline version too. Furthermore the words "offline version" are visible in the title as well as below the very first headline with its creation date and a link to the online version. And finally the value of the robots meta tag was changed to "noindex,nofollow" to reduce duplicate content. Please don't change this value if you upload the offline version of the html files onto a webserver.

What are the differences between the html and the txt/md version of the documentation? [⣾]

The text files (txt and md) are always based on the offline version of their html equivalents. All landmarks and anchors are shown in the text file with their value in curly brackets like {d8}. And all links are marked with a digit in squared brackets like [1]. Their URLs are all listed together after the footer. And furthermore all headlines with their levels are marked with one to three hashes, as the complete text files are written in Markdown. Therefore I'm providing the text version as a txt and as an md file for downloading due to inexperienced users, even when their content is fully equal.

Are the txt/md files of the documentation already prepared for braille printing? [⣞]

Absolutely not. There are different paper sizes around the world as well as different braille tables. And printing the documentation in braille with software, which don't support UTF-8, especially not printing the Unicode characters from U+2800 to U+28FF correctly, makes no sense here. So I'm not going to create such prepared files. In addition I even don't own a braille embosser for testing.

What does the braille character in the squared brackets after every question mean? [⡺]

They are representing the hexadecimal number of the question in HUC8 style. If you click on them, you will get the link to their corresponding question. Therefore the FAQ section is expanded by default, otherwise these anchors wouldn't work. And please note that these anchors were firstly introduced on Friday, April 5, 2019. Therefore new added questions from this date on will interrupt the ascending order, as the relation between a question and its number won't be changed.

Is it possible to save the state of the accordions on the website? [⠺]

In the online version: No; in the offline version: Yes. Just open the downloaded html file with Notepad++ and search for the opening <details> tag. Then add or delete " open" directly in front of the closing angle bracket (">") and save the changes.

Why are you calling the Unicode character "Grinning Face" as an emoji and not as an emoticon? [⢺]

Honestly, in this case emoji, emoticon and smiley would be all correct the same way, because this Unicode character is assigned in the Unicode block named "Emoticons" in English. But as an emoticon is also a combination of characters, which represent smileys and other pictographs too, called this Unicode character as an emoticon could confuse somebody. The HUC Braille Tables don't change the kind of displaying emoticons such as :-) for the grinning face. The Unicode character 😀 (U+1F600) and the emoticon :-) mean the same thing, but they are written down and saved completely different. And last but not least there are thousands of emojis, which are representing more than only a few smileys.

Do the HUC Braille Tables work with NVDA 2017.3 on Windows XP/Vista? [⣚]

Yes, just follow the installation instructions for NVDA 2019.1. NVDA 2017.3, which can be downloaded here, is the latest version which still supports Windows XP SP3 and Windows Vista SP2. NVDA 2017.4 (and higher) requires Windows 7 SP1.

Do the HUC Braille Tables work with other screen readers or with embosser printing software and also on other operating systems too? [⡚]

Maybe. I can't say this in more detail, because I only tested them with NVDA.

I got an alert from my antivirus solution regarding the HUC Braille Tables files. What shall I do now? [⢚]

Please compare the SHA-256 check sum of the files you had downloaded with the SHA-256 check sums, which stand directly below a download link. You can use 7-Zip to do this. The SHA-256 must be equal. If not, delete the file and re-download it again. If you want to get a list of all SHA-256 check sums of all tbl and tbi files too, please download the corresponding text files on the downloads page at Daniel Mayr.at (only available in German). All HUC Braille Tables files were uploaded to and checked by VirusTotal. Just enter the SHA-256 in the search box on its website to get the scan results of its file.

7-Zip shows me the error "Can not open output file : Access denied". Why? [⠚]

Because you don't have the permission to write in the folder you had chosen. Use another destination folder or run 7-Zip as administrator.

How much storage is required for the HUC Braille Tables after unpacking the 7z archives? [⣡]

The HUC8 Braille Tables (version 2019-03-01) require 37.2 MB and the HUC6 Braille Tables (version 2019-05-01) 38.9 MB. But note that you only need one single tbl and one single tbi file for each UTF-16 variant. So the UTF-16 parts of the HUC Braille Tables need only 1.75 MB respectively 1.94 MB. And yes, you read correctly – both 7z archives are smaller than the smallest tbi file within them, which is amazing.

How do I find the correct braille table file, in which the include command have to be inserted? [⠅]

This is a very good question, especially because of Liblouis issue #423 called "Table renaming", which state was still open in March 2019. In most cases the language, the country and the grade can be read directly from the file name. As long as you didn't edit any files in the "louis\tables\" folder in the past, you can insert the include command with low risk, because you can copy the original files directly from the Liblouis gz file or from the NVDA installer. Just open those files with 7-Zip and move to the folder "tables". But if you edited the corresponding files in the "louis\tables\" folder in the past, please back them up first before following the installation instructions for NVDA 2019.1.

After inserting the include command into a braille table, nothing happens. Why? [⡅]

Please read and follow the installation instructions for NVDA 2019.1 step by step. Maybe you only forgot to save the file in Notepad++ or to restart NVDA. If restarting NVDA also doesn't help, please ensure that you edited the correct braille table. And don't forget to insert a line break after the include command. The very last line of a braille table must always be blank.

After updating NVDA I got the previous behavior regarding undefined characters back. The HUC Braille Tables seems not to work anymore. What happened? [⠥]

As the NVDA installer overwrite all existing braille tables files with their equivalents in the installer, the last two steps in the installation instructions for NVDA 2019.1 must be repeated.

There is absolutely no longer any braille output after following the installation instructions for NVDA 2019.1. Why? [⢥]

Ensure that you didn't include the UTF-32 HUC Braille Tables, because they don't work with NVDA 2019.1. Please use the UTF-16 HUC Braille Tables instead. And don't forget to insert a line break after the include command. The very last line of a braille table must always be blank.

All characters of the word at the cursor are now shown with their hexadecimal value. Why does this happen? [⢅]

Because the option "Expand to computer braille for the word at the cursor" in the Braille NVDA settings is enabled. Please disable it by opening the NVDA settings via the NVDA menu and switching to the category "Braille". If you need this feature for contracted braille tables, it might be better to include the HUC Braille Tables in another table, which you normally don't use. There you can include you normal used braille table followed by the HUC Braille Tables. Or you just comment out some definitions in the tbi files itself, so they can't longer interrupt here. Please also read question No. ⣥ and No. ⣅ for more details how to do this.

The option "Expand to computer braille for the word at the cursor" in the Braille NVDA settings is disabled, but some characters and/or some specific combination of characters are still shown with their hexadecimal value. How do I disable this behavior? [⠁]

I recognized such behaviors during my tests in April 2019 with the HUC6 Braille Tables (UTF-16) by including them into English, German and French contracted braille tables. Please note that including the HUC Braille Tables at the bottom of another braille table works, but it isn't the way I supposed the HUC Braille Tables should be primary used as Unicode characters are defined multiple times after including them into another braille table. But as there is no other solution in NVDA 2019.1 yet, the only way to fix this issue is to comment the Unicode characters U+0009 and U+0020 to U+007E out by insert a hash ("#") directly in front of each "sign". Depending on the primary braille table you are using, it could be that even more Unicode characters have to be commented out too. Please read question No. ⣅ for more details how to do this.

All characters are now shown with their hexadecimal value. Why does this happen? [⡥]

Because you didn't insert the include command at the end of the table. Note that contracted tables also include other braille tables. Ensure that you had edited the correct one.

Is it possible to display only the HUC Braille Tables output? [⣥]

Yes. Open a braille table file, which you normally don't use, with Notepad++ and delete every below the header. Then include one of the four tbl files. Save it, restart NVDA and choose the previous edited braille table via the Braille NVDA settings. Depending where and how NVDA is installed, administrator privileges are required to save the edited braille table.

Spaces and non-breaking spaces are still displayed as ⠀ (dot 0) while using the HUC Braille Tables output alone. Is it possible to display these two Unicode characters with their hexadecimal value as well? [⠇]

Yes, but before it should be mentioned that the hexadecimal value is only displayed correctly if the option "Expand to computer braille for the word at the cursor" in the Braille NVDA settings is enabled and if the cursor is located directly in front of a space or in front of a non-breaking space. As this isn't the expected behavior here, two new definitions have to be added to the HUC Braille Tables. So open "huc8-u+0000-u+ffff.tbi" with Notepad++, search for "0020" and add "always \x0020 13678-245678-12678" below that line. Furthermore search for "00a0" and add "always \x00a0 13678-245678-4678" below that line. And for the file "huc6-u+0000-u+ffff.tbi" "always \x0020 123456-2456-1234-2345" and "always \x00a0 123456-2456-145-2345" have to be added below these lines. Please don't delete or comment out the same lines starting with "sign" because both kinds of definitions are required, otherwise the braille output could fail. Then save the changed file, restart NVDA and now it should work as expected. Depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Table.

Is it possible to exclude certain Unicode code points from the HUC Braille Tables, so that only specific ranges of Unicode code points are displayed based on the HUC Braille Tables definitions? [⣅]

Yes, just edit the specific tbi file of the HUC Braille Tables with Notepad++ and insert a hash ("#") directly in front of all Unicode code points which shouldn't be displayed longer with three to five braille characters. But note that every HUC Braille Table contains 65,536 entries. And depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Tables.

Is it possible to exclude the tbi files regarding the Unicode range from U+30000 to U+10FFFF, as there are only 337 characters assigned in these planes in Unicode 12.0? [⡡]

Yes, just open the file "huc8-utf32.tbl" or the file "huc6-utf32.tbl" of the HUC Braille Tables with Notepad++ and insert a hash ("#") directly in front of the "include huc…" of all Unicode planes which shouldn't be included aby longer. Depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Tables.

Is it possible to set different prefix braille characters? [⠡]

Yes, just edit the specific tbi file of the HUC Braille Tables with Notepad++ and replace all existing " 13678-", " 134678-", " 1345678-", " 135678-" and " 123456-" with the braille dots you want. Please always ensure that the first character must be a space and the last one a dash, otherwise other dot combinations are changed too or the whole table gets invalid. And depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Tables.

Is it possible to delete all prefix braille characters? [⣣]

Yes, just edit the specific tbi file of the HUC Braille Tables with Notepad++ and replace all existing " 13678-", " 134678-", " 1345678-", " 135678-" and " 123456-" with a single space (" "). Please always ensure that the first character must be a space and the last one a dash, otherwise other dot combinations are changed too or the whole table gets invalid. And depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Tables.

Is it possible to set different suffix braille characters? [⢡]

Yes, just edit the specific tbi file of the HUC Braille Tables with Notepad++ and replace all existing suffix braille characters with the braille dots you want. But please note that the fourth and the fifth braille characters in the HUC6 Braille Tables are always a combination of a hexadecimal value and the suffix braille character itself. So you have to replace more often to catch them all. Furthermore always ensure that the first character must be a dash and the last one a LF line break (U+000A, "\n" in Notepad++), otherwise other dot combinations are changed too or the whole table gets invalid. And depending where and how NVDA is installed, administrator privileges are required to save the changed HUC Braille Tables.

Can I use the HUC Braille Tables as an input braille table too? [⣁]

Maybe. I can't say this in more detail, because I don't use a braille keyboard. So I couldn't test this.