Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the HUC8 and the HUC6 Braille Tables #730

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@DrSooom
Copy link

commented May 2, 2019

Link to issue number:

Closes #688
Closes #689

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 '\x0030'. For further information please take a look at the official documentation (Wayback Machine).

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.
And please note that UTF-16 end applications require only four files with a total file size of 3.70 MB. The complete HUC Braille Tables require 76.1 MB. See also question No. ⣡.

Testing performed:

  1. Included the UTF16 variants of the HUC8 and the HUC6 Braille Tables into some English, German and French braille tables in NVDA. See also this installation instruction in the official documentation.
  2. Furthermore the HUC8 and the HUC6 Braille Tables were also tested as stand-alone tables in NVDA. See question No. ⣥.

Pending tasks:

  1. Check all definitions primary in the files "huc8-u+0000-u+ffff.tbi" and "huc6-u+0000-u+ffff.tbi". If the first 256 entries in the file "huc8-u+0000-u+ffff.tbi" are correct, then from here on you just have to check every 256th entry. And for the file "huc6-u+0000-u+ffff.tbi" the first 16 entries have to be check followed by every 16th entry. If these two files don't contain any errors, then you just you only have to check the very first entry of all the other 32 tbi files due to Copy&Paste.
  2. Braille input testing. I only checked the braille output.
  3. And as NVDA 2019.1 only supports UTF-16, I wasn't able to test the UTF-32 variants.
  4. And please don't ask me how YAML tests should be created for such kind of braille tables.

Known issues with pull request:

  1. The "include" command at the very end of a file might not be the perfect way how the HUC Braille Tables should be used. Due to multiple definitions computer braille issues sometimes could raise, which can be easily fix by commenting some code points out in the HUC Braille Tables. See also question No. ⢅, No. ⠁ and No. ⣅ in the official documentation.
  2. The stand-alone tests succeeded without raising errors. Well, spaces were still only shown in the HUC style while the cursor is directly in front of it and the option "Expand to computer braille for the word at the cursor" in the Braille NVDA settings is enabled in NVDA – otherwise they were displayed as ⠀ (dot 0). (I will add this behavior to the FAQ section in the next update of the documentation.)
@DrSooom

This comment has been minimized.

Copy link
Author

commented May 3, 2019

I recently added question No. ⠇ (Wayback Machine) regarding how spaces and non-breaking spaces are displayed.

@DrSooom

This comment has been minimized.

Copy link
Author

commented May 4, 2019

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.

@bertfrees

This comment has been minimized.

Copy link
Member

commented May 16, 2019

Looks good!

Sorry, I uploaded all 38 files to the root folder and not to the "tables" folder.

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.

@DrSooom

This comment has been minimized.

Copy link
Author

commented May 17, 2019

Regarding the naming: shouldn't the ".tbl" extension in huc6-utf16.tbl etc. be changed to ".tbi"?

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.

Will this table ever be used standalone?

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.