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 Braille support #837

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

jnaskali
Copy link

Description

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

Requirements / Checklist

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)

example image
Screenshot by dominikheinz from the related issue.

@Finii
Copy link
Collaborator

Finii commented May 29, 2022

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

font-patcher Outdated Show resolved Hide resolved
@Finii
Copy link
Collaborator

Finii commented May 29, 2022

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
Copy link
Collaborator

Finii commented May 29, 2022

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
Copy link
Collaborator

Finii commented Jun 1, 2022

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

@Finii Finii added the not ready label Jun 1, 2022
@Finii
Copy link
Collaborator

Finii commented Jun 2, 2022

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:
image

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

image

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
Copy link
Collaborator

Finii commented Sep 7, 2022

Rebase on master, force push

@Finii
Copy link
Collaborator

Finii commented Sep 7, 2022

All the readmes need an update for the new parameter 🛑

@Finii Finii added this to the v2.3.0 milestone Sep 7, 2022
@musjj
Copy link

musjj commented Sep 7, 2022

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):
image
After:
image

@Finii
Copy link
Collaborator

Finii commented Sep 8, 2022

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
Copy link

musjj commented Sep 8, 2022

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:
image

And the PR implementing this: wez/wezterm#919

@Finii
Copy link
Collaborator

Finii commented Sep 8, 2022

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?

image
Example of more squarish cells

@Finii
Copy link
Collaborator

Finii commented Sep 8, 2022

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
Copy link
Collaborator

Finii commented Sep 24, 2022

@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:

dragon

@musjj
Copy link

musjj commented Sep 28, 2022

Here you go:

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

Rendered in Vim with Wezterm:
image

@Finii
Copy link
Collaborator

Finii commented Oct 13, 2022

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

@Finii
Copy link
Collaborator

Finii commented Oct 13, 2022

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:

image

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:

image

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
Copy link
Collaborator

Finii commented Oct 13, 2022

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
Copy link

musjj commented Oct 18, 2022

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
Copy link
Collaborator

Finii commented Jan 22, 2023

@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
Copy link
Collaborator

Finii commented Feb 20, 2023

@Finii Finii added this to the Parallel Universe milestone Mar 10, 2023
@Finii
Copy link
Collaborator

Finii commented Mar 10, 2023

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.

@Finii Finii closed this Mar 10, 2023
@PhMajerus
Copy link

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

image

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
Copy link
Collaborator

Finii commented Jan 21, 2024

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

@flexiondotorg
Copy link

@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:

I've successfully patched the fonts I wanted 🙂

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

@Finii Finii force-pushed the braille-support branch from ec695c7 to 3578d0a Compare July 16, 2024 08:21
@Finii
Copy link
Collaborator

Finii commented Jul 16, 2024

@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

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:

image

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

image

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 pushed a commit to jnaskali/nerd-fonts that referenced this pull request Jul 16, 2024
@Finii
Copy link
Collaborator

Finii commented Jul 16, 2024

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

image

Interestingly it is ok in upstreams UBraille.sdf 😬

image

@flexiondotorg
Copy link

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 Excelsior Test

Fixedsys Core

Fixedsys Core Test

@flexiondotorg
Copy link

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.

Is CC0 licensed acceptable?

@Finii Finii force-pushed the braille-support branch from 3578d0a to de5eacf Compare July 16, 2024 09:16
@Finii
Copy link
Collaborator

Finii commented Jul 16, 2024

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.

flexiondotorg added a commit to wimpysworld/nix-config that referenced this pull request Jul 16, 2024
@Finii
Copy link
Collaborator

Finii commented Jul 16, 2024

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 <sdiconov@mail.ru>

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.

[why]
To be on the safe side we use a font with a well defined license that
puts no restrictions upon us and our users from GGbotnet.

Suggested-by: Martin Wimpress <@flexiondotorg>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
@Finii
Copy link
Collaborator

Finii commented Jul 16, 2024

Waaaah 😭

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

image

Braille 3478

image
left: BrailleCC0, right: UBraille

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

image

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
Copy link

PhMajerus commented Jul 17, 2024

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:
image

Braille with the Separated Octants style:
image

Octants:
image

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

Separated Sextants:
image

Sextants:
image

@Finii
Copy link
Collaborator

Finii commented Jul 17, 2024

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for Braille Characters?
7 participants