Add Braille support

[jnaskali]

Description

Adds braille support to render pixelart (e.g. in terminal applications) requested in #482.
Thanks @Chaz6 for the implementation idea!

Requirements / Checklist

• Read the Contributing Guidelines
• Verified the license of UBraille.ttf to be GPL 2

What does this Pull Request (PR) do?

Adds UBraille.ttf to glyph sources and updates font-patcher so that it copies symbols from 0x2800 to 0x28FF.

How should this be manually tested?

Check that fonts are created correctly.

Any background context you can provide?

What are the relevant tickets (if any)?

Closes #482.

Screenshots (if appropriate or helpful)

Screenshot by dominikheinz from the related issue.

[Finii]

Great work creating this PR 👍

Source of the glyphs mentioned in commit: ✔️

As this is not in a PUA, I think maybe it should be careful to preserve pre-existing glyphs. It is possible to have it in the attributes even it is not used by any patch set at the moment. (Compare diff comments on attributes below).
"Think maybe" => open question

[Finii]

I guess we need a ScaleGlyph here, to have a working mono version?
About the ScaleGlyph ... without one the patching will maximize the size of each glyph individually to fill the 'cell' completely. But with Braille you want to scale all glyphs identical to keep the relative size/position differences intact.

Further the 'Attributes': SYM_ATTR_DEFAULT seems an odd choice, as that means 'align': 'c', 'valign': 'c', 'stretch': 'pa'. That does only make sense if a ScaleGlyph is active? And maybe we want a careful here?

Also maybe correct the whitespaces, the vertical alignment (nothing I like normally, but we have it here) is broken as you see from the diff. Maybe a tab instead of spaces?

[jnaskali]

Thank you for looking through the code. I amended with the vertical alignment and moved the issue number to a line of its own in the commit message.

I'm afraid I don't know enough about fonts to touch the attributes, so (everyone) feel free to improve things.

[Finii]

Here the scale effect for illustration:

Lets fix it...

[Finii]

Fixed in additional commit:

[Finii]

After some thought I believe we do not want careful here, at least not a partial one.
If there is any glyph in the range it will not match our new glyphs in style and size.
I guess best is to not be careful here.

[Finii]

OH NOO, it is not working, the scaling is uniform but the centering is individual? Now we have a lot centered single dots!

Examining...

[Finii]

Well, ScaleGlyph can not (by design) enforce consistent shifting/centering.

This needs some thought.

[Finii]

Additional note

If you edit the commit, maybe you could add to the commit message the Fixes: #837 line (on a line of its own at the bottom).
That makes it easier to go from git blame to the Issue and the MR.

[Finii]

Same font packaged here: https://aur.archlinux.org/packages/ttf-ubraille

The font contains this copyright notice
Created by Vyacheslav Dikonov with PfaEdit 1.0 (http://pfaedit.sf.net). Free to use and distribute.

Same font is mentioned here https://fontforge.org/archive/sfds/index.html as 'GNU licensed'

Note that GNU FreeFont uses a Braille set by Steve White link.

[Finii]

For me this looks good to merge now; playing the ball to @ryanoasis

[Finii]

It's a whole lot more involved than I initially thought. Split that up into individual commits that introduce the changes step by step.

Looks good now:

The changes are (mostly) only active when patching in the Braille font.

Also noticed that one glyph in the source font is missing: dots-67 is empty

Although it should have dot 6 (2nd colum, 3rd from top) and dot 7 (1st column, lowest row) active - as the tiny fontforge preview shows. I have no clue about Braille (maybe it is not needed), but it can lead to 'broken' displays in the usecase shown in the top of the Issue (use as graphical elements).

[Finii]

Rebase on master, force push

[Finii]

All the readmes need an update for the new parameter 🛑

[musjj]

Can this potentially fix the issue of gaps between the top and bottom of braille glyphs? Some terminals custom render them to make sure the gaps are filled, but can this issue be solved from the font level?

I noticed the commit regarding padding, so I tried out the PR out of curiosity to see what differences does it make, but it seems that this patch just makes the gaps even bigger.

(Tested on JetBrainsMono)
Before (old screenshot, ignore the colors):

After:

[Finii]

Ah, what you would like is a stretch-x-y glyph rescale (like the powerline glyphs).

That would be nice in graphic scenarios like above, but look funny in normal (i.e. displaying actual braille text) ones, because the dots will get distorted. Hmm.

I can try a bit with that image above, but ... ping me if it takes too long, I might have forgotten to do it :-}

[musjj]

Cool, looking forward to it :)
Do you think the dots need to be distorted? For reference, this is how it looks like in Wezterm, with the custom glyph rendering:

And the PR implementing this: wez/wezterm#919

[Finii]

Do you think the dots need to be distorted?

Well, the 'cells' of some fonts are rectangular, more high than wide, like your cursor in the image above.
But some fonts have almost square 'cells'. If the dots are to 'fill' the 'cell' completely they must be scaled differently in X and Y, thus loosing the aspect ratio, thus round things can become ... ellipses?

Example of more squarish cells

[Finii]

And the PR implementing this: wez/wezterm#919

Ah, they do not patch in a scaled source, they create the glyphs on the fly from circles drawn in the 'cell'.
That would also be possible, but more complex. Normally Nerd Fonts just aggregates glyphs, not creates new ones.

[Finii]

@musjj Could you copy & paste that image into a comment here, so that I could try it?

I tried with this image, but that looks a bit fuzzy:

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⢈⣈⣌⣌⣬⡮⡦⠲⠳⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⣈⣌⣮⣮⣿⣿⣿⣿⠻⠓⠑⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣌⣬⣮⣮⣮⣎⣌⣌⣮⣿⣿⣿⣿⣿⣿⣿⣿⣝⣝⣝⣮⣮⣮⣮⣎⣌⣌⣌⣮⣮⣮⣮⣮⣮⣮⣮⣮⣾⣿⣿⡷⡷⠷⠳⠓⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠓⠁⠀⠀⣑⣽⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣟⢙⢙⢉⢈⢈⢈⢈⠈⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣈⣌⣮⣿⣿⡷⢳⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢻⠳⠳⠓⠑⠑⠑⠑⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⢀⢈⢈⣌⣿⣿⣿⣿⣿⣮⣮⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣟⠻⡳⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⣎⢈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⣠⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠏⠱⣷⣟⠳⠆⠀⣳⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣞⠙⠳⡷⣷⣿⣿⣯⢌⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠰⣷⣿⣿⣿⣿⡿⠳⠑⠑⠑⠳⠳⡳⡷⡷⡷⡷⠷⠀⠀⠀⠱⡇⠀⠀⣰⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣎⠈⠀⠐⠱⡷⣿⣯⢌⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠑⠳⡳⠳⠁⠀⠀⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⣬⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⠌⠀⠀⠀⠀⠱⡳⣏⠈⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠑⡳⣧⣮⣎⣌⣌⣌⣌⣌⣌⣌⣬⣮⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠌⠀⠀⠀⠀⠀⠀⠁⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⢈⢈⢘⢹⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠱⣷⣿⣿⣿⣿⣯⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣈⣮⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠗⠀⠀⠰⣿⣿⣿⣿⡿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣬⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠓⠁⠀⠀⠀⠀⣱⣿⣿⣿⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⢀⣬⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠷⠓⠀⠀⠀⠀⠀⠀⠀⣰⣿⡿⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⣨⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠷⠳⢓⣽⣿⣿⡷⠳⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⣸⠷⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⣼⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠓⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⡣⣦⣎⣌⢈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⣸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⡳⣿⣿⣯⣎⢈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⠱⣷⣿⢏⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⠈⠀⠀⠀⢈⢈⢈⢹⣷⣿⣿⣯⣎⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⠈⠱⡷⣏⢈⠀⠀⠀⠀⠀⠀⠀⠑⣳⣯⣎⠈⢙⣿⣿⣿⣿⣿⣿⣿⣿⣿⣎⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠰⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣮⣌⢘⠑⠁⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢎⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠰⣿⣿⣿⡿⠱⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡷⠳⠁⠀⢀⣨⣿⣿⣿⣿⣿⣿⠷⠳⠳⠳⡷⣿⣿⣿⣿⣿⠎⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠐⣷⣿⠃⠀⠐⣷⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣟⣍⣌⣌⣌⣌⣮⣿⣿⣿⣿⣿⣿⣿⠃⠀⠀⠀⠀⠀⠰⣿⣿⣿⣿⣏⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠑⠀⠀⠀⣰⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣿⣿⣿⣿⣎⡾⠃⠀⠀⠀⠀⣿⣷⣿⣿⠟⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣸⣿⣿⣿⣿⡿⠓⠳⡳⣷⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢍⠀⠀⣷⣿⣿⣟⣝⢈⢈⣌⠀⠀⠀⠓⣰⣿⣿⠇⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣬⣿⣿⣿⠷⠑⠀⠀⠀⠀⠀⠐⠱⠳⡷⡗⠱⡳⡷⣿⣿⣿⣿⢏⠀⠀⠐⠑⠑⠑⠑⠑⠀⠀⠀⠀⠀⣼⣿⠿⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⢈⣌⣮⡿⡷⠳⠑⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⣿⣿⡿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣿⠷⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠲⠳⠑⠑⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⠷⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣈⡿⠓⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⡶⠓⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

(I created that with https://image2ascii.com/)
Maybe their algorithm expects the dots at other codepoints?

Here is the source image, with very smooth borders:

[musjj]

Here you go:

  ⣴⣶⣤⡤⠦⣤⣀⣤⠆     ⣈⣭⣿⣶⣿⣦⣼⣆         
   ⠉⠻⢿⣿⠿⣿⣿⣶⣦⠤⠄⡠⢾⣿⣿⡿⠋⠉⠉⠻⣿⣿⡛⣦      
         ⠈⢿⣿⣟⠦ ⣾⣿⣿⣷    ⠻⠿⢿⣿⣧⣄    
          ⣸⣿⣿⢧ ⢻⠻⣿⣿⣷⣄⣀⠄⠢⣀⡀⠈⠙⠿⠄   
         ⢠⣿⣿⣿⠈    ⣻⣿⣿⣿⣿⣿⣿⣿⣛⣳⣤⣀⣀  
  ⢠⣧⣶⣥⡤⢄ ⣸⣿⣿⠘  ⢀⣴⣿⣿⡿⠛⣿⣿⣧⠈⢿⠿⠟⠛⠻⠿⠄ 
 ⣰⣿⣿⠛⠻⣿⣿⡦⢹⣿⣷   ⢊⣿⣿⡏  ⢸⣿⣿⡇ ⢀⣠⣄⣾⠄  
⣠⣿⠿⠛ ⢀⣿⣿⣷⠘⢿⣿⣦⡀ ⢸⢿⣿⣿⣄ ⣸⣿⣿⡇⣪⣿⡿⠿⣿⣷⡄ 
⠙⠃   ⣼⣿⡟  ⠈⠻⣿⣿⣦⣌⡇⠻⣿⣿⣷⣿⣿⣿ ⣿⣿⡇ ⠛⠻⢷⣄
     ⢻⣿⣿⣄   ⠈⠻⣿⣿⣿⣷⣿⣿⣿⣿⣿⡟ ⠫⢿⣿⡆    
      ⠻⣿⣿⣿⣿⣶⣶⣾⣿⣿⣿⣿⣿⣿⣿⣿⡟⢀⣀⣤⣾⡿⠃    

Rendered in Vim with Wezterm:

[Finii]

Rebase on master, actually rebase on the code added by #916 which has the same problems.
Force push.

[Finii]

Well, I do not know if this is really useful.

The braille glyphs are designed to always have one row of dots empty, so that one can distinguish between 'letters'.
Here is how the font originally looks like:

Dots have the blue diameter.
The leftmost (pale) dot is never there.
Between dots we have a gap of green
And the brown gap in the beginning and end of the glyph together are also one green.

This is in direct contradiction to the image shown above, where there are no visible vertical gaps from the columns of not-existing points.

Here you see the 'empty columns of dots' (arrows), and that they are missing in Wezterm:

This just talks about the vertical gaps, not the horizontal (line to line) ones.

Braille rendered with a font without char-to-char gaps will be unreadable.

[Finii]

Lets assume we do not care if Braille is readable, because ... we are Nerds and Braille is not read from a screen but from a Braille line reader.

To get the padding right...

Horizontally we have (2 * blue + 1 green) * padding% = 1 green
Vertically we have (4 * blue + 3 green) * padding% = 1 green

This is not working if horizontal and vertical padding is the same; which is how it is currently with the patcher.

And for that we would still scale the glyphs not preserving aspect ratio, thereby ending up with ellipsis.

I guess the only good solution (for a graphical display) would be to generate the glyphs while patching the font with adapted gaps. This would also be possible but a totally different approach, rather like Wezterm.

[musjj]

That seems like an interesting approach. Not really sure how fonts work, but thinking about it again, is it actually possible to get rid of the horizontal space between the lines? Aren't they rendered and controlled by the terminal instead of the fonts?
Maybe this isn't possible after all without custom glyph rendering done by the terminal.

[Finii]

is it actually possible to get rid of the horizontal space between the lines?

We get rid of it for the powerline glyphs, right? ;-)

They always touch top and bottom of the line (at least in terminal emulator environments).

[Finii]

Lots of work done here has been transferred to #916. Adding a Braille font after that PR becomes a breeze.
But still I guess we would need to generate the glyphs rather than add a font, for reasons mentioned above.
Maybe there is time for that in the future. For now I will exclude it from v2.3.0. Converting to draft to keep this.

[clort81]

Lets assume we do not care if Braille is readable, because ... we are Nerds and Braille is not read from a screen but from a Braille line reader.

To get the padding right...

Horizontally we have (2 * blue + 1 green) * padding% = 1 green Vertically we have (4 * blue + 3 green) * padding% = 1 green

This is not working if horizontal and vertical padding is the same; which is how it is currently with the patcher.

And for that we would still scale the glyphs not preserving aspect ratio, thereby ending up with ellipsis.

I guess the only good solution (for a graphical display) would be to generate the glyphs while patching the font with adapted gaps. This would also be possible but a totally different approach, rather like Wezterm.

In particular, braille characters are useful as box-drawing characters.

I ask the reader to now take comprehension of a few pertinent facts:

• Fonts are made for people with functional vision. We view font glyphs on screens, with our eyes.
• Blind people do not read braille on screens, with their eyes, which don't work, because they are blind.
• The Braille glyphs add 256 (2^(4x2)) distinct drawing glyphs, which allow us far greater flexibility in drawing to terminal than other glyphs in the BMP range.
• The style of braille glyphs is most useful for drawing when they are connecting blocks, as opposed to dots.

Which looks better to you? Dot-braille or block-braille?


fancy_monitor2.txt.gz

[Finii]

@clort81 Interesting design.
And they (the blocky ones) would not need to be generated for each font but can be patched in using xy scaling. They would be oblong and not square, just fitting the 'Braille grid' into one target font cell.

[Finii]

• Alternate Braille glyphs optimized for pseudographics use microsoft/cascadia-code#647

[Finii]

The future of this is unclear.
The Braille glyphs have a function in unicode, and that is representing Braille.

This PR heads in the direction to re-assign the codepoints to 'some graphics glyphs', what is not exactly right in Unicode context.

So probably this will be only a self-patch option or something.

Moving this to parallel Universe to get it out of the mainstream development.

[PhMajerus]

If you're interested, Unicode accepted another block of octants for 2×4 pseudo-pixels.

U+1CD00 to U+1CDE5 (it isn't the complete 256 semigraphic characters because some patterns already exist as quadrants or half-blocks).
The octants are documented at https://www.unicode.org/L2/L2021/21235r-terminals-supplement.pdf
Their planned inclusion in Unicode 16.0 is shown at https://www.unicode.org/alloc/Pipeline.html

Updating apps using braille to use the new octants should be easy, it should even be possible to write a small conversion utility that can be piped to that switches existing Braille to the new Octants without touching existing utilities that use Braille.

[Finii]

@PhMajerus Thanks for the update. That certainly looks interesting.
I need to have a closer look.