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

Add HUC Braille support #36

Closed
aaclause opened this issue Nov 26, 2019 · 15 comments · Fixed by #39
Closed

Add HUC Braille support #36

aaclause opened this issue Nov 26, 2019 · 15 comments · Fixed by #39

Comments

@aaclause
Copy link
Owner

@aaclause aaclause commented Nov 26, 2019

HUC Braille is another representation for undefined chars designed by @DrSooom. See the official documentation for more info.

Using this HUC-Braille converter, I'd like to implement this alternative in BrailleExtender.

In this scope, we need review the option — Show undefined characters as... —. I suggest:

  • A new label: Representation of undefined characters
  • A list box with the following choices:
    • Use braille table behavior (default)
    • Dots 1-8 (⣿)
    • Dots 1-6 (⠿)
    • Empty cell (⠀)
    • Question mark (depending output table)
    • Other dot patterns (to be filled in an edit box)
    • Hexadecimal, Liblouis style
    • Hexadecimal, HUC8
    • Hexadecimal, HUC6

Also I'd like to try to implement the possibility to — Use HUC8/HUC6 for braille input —. Maybe a special temporary mode for that (?).

Limitation: due to the end of Python 2 in January and other technical issues with Python 2 and Unicode, This feature will require Python 3.

Any though @DrSooom, @zstanecic?

@zstanecic
Copy link
Collaborator

@zstanecic zstanecic commented Nov 27, 2019

@DrSooom
Copy link

@DrSooom DrSooom commented Nov 27, 2019

@zstanecic: The implementation of the HUC Braille Tables into the BrailleExtender will and MUST be a different one than the way I describe here (= just including the complete tbl/tbi files). Due to @Andre9642's script it's (theoretically) already possible to limited the HUC8 and HUC6 definitions only to a limited code point range. Furthermore it could be also possible that @Andre9642 is able to merge existing braille tables with parts of the HUC Braille Tables by using a script. So the definitions in the original braille tables always win, as this process will no longer produce multiple definitions – which is currently the case with my HUC Braille Tables if you are completely including them into other braille tables.

See also: liblouis/liblouis#868 and liblouis/liblouis#869

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Nov 27, 2019

@zstanecic In addition to Daniel's answer, I think I'll do as follows on the first attempt:

First, add an 'undefined' rule to the current table. E.g.:
undefined 78-12345678-78

Then, for each string to translate (i.e. each string sent to liblouis):

  1. Retrieve the liblouis translation.
  2. If the braille string contains at least one "⣀⣿⣀" occurrence, replace all these occurrences by their corresponding HUC representation (using the original string and — HUC-braille converter —).
  3. Show the string on the braille display.

@DrSooom
Copy link

@DrSooom DrSooom commented Dec 5, 2019

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Dec 13, 2019

@DrSooom Thank you for the clarification.
I also planned to implement the possibility to:

  • Limit the HUC8 and HUC6 definitions only to a limited code point ranges.
  • Customize prefix braille characters.

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 10, 2020

Hi @DrSooom, and happy new year!
I've just added a first implementation of HUC Braille in input.
Currently, only HUC8 works (HUC6 is more complicated to implement). Also, this feature works only with NVDA 2019.3 (due to Python 3).

To test this:

  1. Enable the — HUC Braille input — mode.
  2. Type your HUC Braille patterns on the braille display. E.g.: ⣭⠤⠕ for 🍑, ⣭⢤⡙ for 👍, ⣭⡤⣺ for 😀.

By default, to enable/disable the — HUC Braille input — mode, press NVDA+Windows+h or dots(1+2+5+8)+space on braille displays supported. Otherwise define another gesture for this feature.

Any suggestion?

@zstanecic
Copy link
Collaborator

@zstanecic zstanecic commented Jan 10, 2020

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 10, 2020

Hi @zstanecic,
The feature is still in development. When the feature is ready, I'll merge it.
For now, you can test the feature if you are under the dev channel.
Thanks

@DrSooom
Copy link

@DrSooom DrSooom commented Jan 11, 2020

@Andre9642: I don't own a braille display with a braille keyboard. Is there another way to test this?

@zstanecic: This link will always open the latest dev version of the BrailleExtender. Currently it's 20.01.10-dev.

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 11, 2020

@DrSooom you can test this with pcKeyboardBrailleInput add-on -> https://addons.nvda-project.org/addons/pcKeyboardBrailleInput.en.html
In this mode, I'll also add the possibility to type a character from its hexadecimal/decimal/octal/binary value.
E.g. (braille inputs): (x1f606 or d128518 or o373006 or b11111011000000110) then space -> 😆.

@DrSooom
Copy link

@DrSooom DrSooom commented Jan 11, 2020

Small typo in the GUI (dropdown list): "Other dot patterns" » "Other dot pattern"

And the Liblouis style output is incorrect. Code points from U+10000 to U+FFFFF starts with '\y and those from U+100000 to U+10FFFF with '\z000. '\x only stands for code points between U+0000 and U+FFFF.

The rest works correctly – as far as I see (with NVDA 2019.3 Beta 1). Very, very good job. 👍

The Braille input test follows later. And should I also test the braille output with NVDA 2019.2.1 as well? Or does this version of the BrailleExtender no longer work with NVDA 2019.2.1?

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 11, 2020

'HUC Braille input mode' becomes 'advanced braille input mode'
This mode still supports HUC8. Also it's now possible to type a character from its binary/decimal/hexadecimal/octal value
New default gestures: NVDA+Windows+i and ⠊+space for braille displays supported (previous is in conflict with f8).

— commit 9dc8cfc

@DrSooom thanks for your comments. I'll fix those.
Regarding NVDA 2019.2.1 and lower, I'd like to keep the compatibility until NVDA 2020.1 is out. Unfortunately, some features will be limited.

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 15, 2020

Hi @DrSooom,
Would you mind writing me a short text presenting the HUC Braille that I could include in the documentation?
The aim would be to encourage the use of this feature, including for the input. Don't forget to include the link to the official documentation.
Personally, I like this system, especially for write emojis! 😀 = ⣭⡤⣺, 😆 = ⣭⡤⡾, 👍 = ⣭⢤⡙… It's so great!

@DrSooom
Copy link

@DrSooom DrSooom commented Jan 15, 2020

@Andre9642: I'm really sorry, but currently I must manually migrate the main content of my website (more than 1100 posts) into a complete new self-developed backend due to an upcoming php upgrade in February 2020. And I really have to hurry up here. Therefore I sadly cannot help you until the main part of the migration process was finished. If I don't do that, my website will get broken in February 2020. The HUC Braille Tables website isn't affected by the way – as it doesn't contain any php content. In the meantime you can use parts of the content of the Readme file of HUCv2, as this file is licensed under LGPL 2.1. To give you a suitable text, I will have to rewrite some parts of the documentation and also translate these parts into German. And for this process I sadly haven't the time yet. Thanks for your understanding.

@aaclause
Copy link
Owner Author

@aaclause aaclause commented Jan 16, 2020

No problem, don't worry. Thanks and good luck!

@aaclause aaclause closed this in #39 May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants