Adding the HUC8 and the HUC6 Braille Tables #730
Link to issue number:
Summary of the issue:
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
Description of how this pull request fixes the issue:
This PR only adds all tbi and tbl files of the HUC8 and the HUC6 Braille Tables. It doesn't change any other braille tables. How the HUC Braille Tables are used like a secondary braille table (don't confuse it with the "include" command) still has to be done in another PR – or even in the end application. See also nvaccess/nvda#8702.
Known issues with pull request:
I already thought that I have overlooked something. Sorry, I uploaded all 38 files to the root folder and not to the "tables" folder. As the 34 tbi files are too large for editing at the GitHub website, which is required for moving them, I hope that you are able to move these 38 files to the correct folder. Otherwise I have to delete and upload them again.
Don't worry, we can fix that.
I think a YAML test would be great, but I will take care of that too.
Regarding the naming: shouldn't the ".tbl" extension in huc6-utf16.tbl etc. be changed to ".tbi"? Will this table ever be used standalone?
Because these tables use up quite a lot of space, I was thinking of maybe storing them in compressed form? We could also omit the part that is only needed for UTF-32 applications in the UTF-16 build.
I was already thinking about this at the beginning of the creation process and I decided that the four head files should be recognized in an easier way. Furthermore including them just into other tables isn't the best solution due to multiple definitions. (Please read the FAQ for more details.) Maybe later on the end application could use the HUC Braille Tables as a secondary braille table for braille output only. This should eliminate the multiple definitions problems. And finally it's easier just to name the four tbl files in the manual instead of explaining the whole structure of the HUC Braille Tables. As the HUC Braille Tables contains two levels, these levels should be represented by their file ending too.
It is possible, but not recommended. Well, but maybe some nerds want to recognize respectively want to read the code points of Unicode characters alone. But as I already wrote here in the documentation – it isn't the primary way how the HUC Braille Tables should be used. But on the other hand I don't want to block that kind of using the HUC Braille Tables, as I haven't the permission to decide this. I want to keep both ways open. Therefore two new entries in the braille output list in NVDA for the HUC Braille Tables (stand-alone) would be nice too. CC: @leonardder
I suggest to add a new option for the building process. As UTF-16 end applications don't need 34 of the 38 files, they should be of course omitted. Therefore I created two tbl files for UTF-16 and two tbl files for UTF-32 end applications. UTF-32 end applications don't need the "*-utf16.tbl" files, vice versa. So if the developer already knows, which UTF encoding format is used, he just have to choose the correct tbl files for extending other braille tables. I tried to keep the whole using/including process of the HUC Braille Tables as simple as possible for everybody. Therefore I created the two files "huc8-utf16.tbl" and "huc6-utf16.tbl" as well, even if they aren't really required. But having them makes the explanation much easier.
As I mentioned in #689 (comment), I think this should not go in as such. @DrSooom you are of course free to distribute the tables separately, but I think a better approach would be to add a new mode to liblouis. This new mode will then invoke some code that will emit HUC Braille for unknown Unicode characters as opposed to the escaped Unicode which is the current functionality