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]

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.

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

[flexiondotorg]

@Finii I wanted to revive some old fonts by adding Nerd Fonts and, as it turns out, Braille.

I have taken the relevant parts from this patch, updated them and applied them to nerd-font-patcher 3.1.1 (script version 4.8.2) in a custom Nix package. Here is the 13-line patch:

• wimpysworld/nix-config@141b76e

I've successfully patched the fonts I wanted 🙂

Would you like me to submit an updated pull request here?

[Finii]

@flexiondotorg Thanks for the work on this. I would rather keep this 'the' PR about Braille, instead of having two PRs with diverging discussions. I will pull your commit in a minute.

Also wanted to mention, after skimming the comments above, that this PR's problems are not technical (anymore, as the needed algorithm changes are already merged) but conceptual.

Just some issues

• Shall Braille glyphs be usable for Braille (which means gaps for graphics)
• If for graphics use, scaling 'pa' will never work nicely - also 'xy' does not scale nicely on dots that become ellipses
• Blocks instead of dots will have overlap or inter-line and inter-glpyh gap problems depending on terminal
• Unicode accepted another block of octants for 2×4 pseudo-pixels
• Cascadia ended up adding both (blocks in new unicode block, and dots as classic Braille)
  New diagonals, octants, sedecimants & eights, separated quadrants & sextants, segmented digits, and large type pieces microsoft/cascadia-code#723 (comment)

When simply patching like you proposed, depending on target font we will get extraordinary width vertical gaps in graph renderings, i.e. when the font's cell is more square than oblong-tall, see for example Arimo:

And another example LiterationMono, comparison how the box drawing glyphs work that introduce a bit of overlap.

Summary

I guess this works for some fonts but not in general, depending on cell aspect ratio.
And all the hurdles above are unsolved.

Possibly easier would be to autogenerate the glyphs with the right proportions instead of scaling an existing font (for the Braille glyphs), as then we can have dots but avoid big gaps and non-circular dots independent of cell aspect ratio.

[Finii]

And to not forget, Braille-6-7 is still broken in 'upstream' UBraille.ttf (i.e. empty)

Interestingly it is ok in upstreams UBraille.sdf 😬

[flexiondotorg]

Thanks for the summary @Finii 👍

It looks like I got lucky, as the font I most wanted patching (Fixedsys Excelsior) seems to have the ideal aspect ratio for Braille glyphs, and Fixedsys Core is pretty close. The following are from Blackbox, which doesn't have built-in glyphs and uses vte-gtk4 0.76.3.

Fixedsys Excelsior

Fixedsys Core

[flexiondotorg]

And to not forget, Braille-6-7 is still broken in 'upstream' UBraille.ttf (i.e. empty)

There is an alternative Braille font I found that I have not tested yet.

• https://www.fontspace.com/braille-cc0-font-f96789

Is CC0 licensed acceptable?

[Finii]

Is CC0 licensed acceptable?

Sure. But I just exchanged the ttf for the sdf. Force pushed that just a minute ago 😬

Also removed the mentioning of "GPL" because UBraille is certainly not GPL; Yudit is. Maybe wrong, see following comment.

[Finii]

Original statement (in Russian, autotranslated) of UBraille creator Vyacheslav

This font is probably the world's first free Braille font of
the UNICODE standard. The font contains only dot characters
Braille in the range 0x2800 - 28FF. When creating it, the
following was used pfaedit editor and UCS fonts, also known
as -misc-fixed- for XFree86, as a sample. The font can be used
to display Braille text in yudit and other Unicode text editors.

Dikonov Vyacheslav, 2002

This is probably the first free unicode Braille font in the world.
It contains braille glyphs in the Unicode range of 0x2800 - 28FF only.
I used Linux and pfaedit editor to create this font and UCS bitmap 
fonts to verify the glyph shapes. It can be used in yudit and other
unicode editors to display braille texts.

This font and its source is free to modify, use, distribute, embed 
in documents and other larger scale unicode fonts. If you require 
a license, consider it to be GPL.


Vyacheslav Dikonov, 2002 <[email protected]>

Source: https://fontforge.org/archive/sfds/UBraille.tar.bz2

So is it GPL? Probably not strictly. GPL would impose some restrictions on us. 🤔

But to be safe, the CC0 font is certainly the better choice if we do not self-autogen the glyphs later on.

[Finii]

Waaaah 😭

UBraille is even more broken?!? Comparsion of UBraille and BrailleCC0:

Braille 3478

left: BrailleCC0, right: UBraille

https://en.wikipedia.org/wiki/Braille_pattern_dots-34#Plus_dots_7_and_8

Good that we dropped UBraille!

Edit:

For explanation, the simple 6 dots are positioned like this:

  1    4
  2    5
  3    6

and the extended 8 dot sets add the other dots below

  1    4
  2    5
  3    6
  7    8

[PhMajerus]

I think Braille should not be the same as the 2×4 pseudo-pixels / octants that will be standardized in Unicode 16.0.
However, I also agree that Braille has been historically used as pseudographics in terminals for years, and there may be something to do with them as well to better accomodate that existing use.

With Unicode 16, we'll have separated quadrants (2×2), which are mosaics like the standard quadrants, but in a grid with gaps between pseudo-pixels, as well as both sextants (2×3) and separated sextants, following the same gap concept.
However, while Unicode 16 also adds octants (2×4), it does not add the equivalent separated octants.

You can probably see where I'm going here… to me, Braille could be the separated octants, using the same design as separated quadrants and sextants (grid-compatible with them).
See my suggestion in Cascadia's issues for the full details and examples: microsoft/cascadia-code#739

Here are some examples of that idea with Cascadia:

Braille:

Braille with the Separated Octants style:

Octants:

Note how they follow the styles of Sextants vs Separated Sextants below.

Separated Sextants:

Sextants:

[Finii]

Braille with the Separated Octants style

I am inclined to implement it in this way, as also pointed out by musjj's and flexiondotorg's images.
It will make it useless for real Braille use, though. I think Braille glyphs are for seeing people that want to check Braille software output for example.

I know I will regret that if we get numerous issues that we broke all those Issues in from devs who write software for Braille hardware 😬

But in principle I guess for a Nerd Font it makes most sense to have the glyphs serve as 'generic graphic elements' (i.e. separated octants).

Ah, and further I do not see the Unicode 16 graphics building blocks added here soonish.
In principle I would rather spend the time to switch away from fontforge to be able to patch variable fonts...

Edit: Somehow one sentence was a mix of two sentences

[knghtbrd]

Genuine legally blind person here who has learned and used actual printed Braille on cardstock pages (and a few sheets of magazine stuffed into Braillewriter or slate in a pinch when cardstock wasn't handy!) We actually use Braille for dot graphics and character cell patterns ourselves. Braille dots are a context-dependent code system, not a language nor even necessarily an alphabet.

Yeah, to read text encoded in Braille, the character spacing is important. It's even important that cell spacing be such that ⣿⣿ be clearly two cells consisting of dots 12345678 and NOT three cells consisting of 4568, 12345678, and 1237. Meaning that the space between cells on a line needs to be less than a "missing" column of dots would be, and the space between lines should be slightly more than a missing row (which helps for tracking lines…)

That said, I've actually got some limited vision and I ended up looking at this discussion because I was looking for a font with dots that didn't have those spaces because I wanted them for graphics purposes. I'd say that's a valid use of the symbols, if folks want to use them that way because, like I said, we do ourselves. If you're going to include Braille glyphs, though, I suggest using OTF features to provide two variants—one with "proper" spacing for reading Braille, and one with uniform dot spacing for graphics. Optionally generate two fonts since some things maybe won't let you specify a preference for the alt glyphs?