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

Feature Request: Separated octants mode (stylistic set) for Braille characters #739

Open
PhMajerus opened this issue May 8, 2024 · 1 comment

Comments

@PhMajerus
Copy link
Contributor

PhMajerus commented May 8, 2024

Description of the new feature/enhancement

Now that Windows Terminal supports stylistic sets, I'm bringing back the #647 idea, but as an optional feature.
Many Linux apps have been using braille as pseudo-pixels, to render graphs.

Here is an example with BpyTOP:

image

Cascadia has proper Braille characters, with separations between symbols, and between lines, as intended.
However for this specific use, which is very common in terminals, making the pseudo-pixels evenly spaced is sometimes preferable.

In these scenarios, the extra horizontal and vertical spaces between Braille dots are often considered an inconvenience.
Here is the same app with Braille that does unifies the spaces for graphical use:

image

This is even more visible when apps are rendering more complex graphics using Braille:
image
Which would look like the following with the stylistic set enabled:
image

The desire for evenly spaced Braille dots can also be seen with lot of examples in the ryanoasis/nerd-fonts#837 discussion. Note how some users even consider the proper spacings of Braille as a bug, because they are used to terminal fonts that make all the spaces between the Braille dots even.
Notcurses NCBLIT_BRAILLE also uses Braille as pseudo-pixels, and would benefit from a Separated Octants feature.

It is important to note that the recent introduction of octants does not make this feature useless in the long term. Unicode 16.0 also introduces separated quadrants and separated sextants because sometimes the separation is desired to make the pseudo-pixels more distincts. Braille will likely keep being used for that purpose, and many existing and future CLI/TUI apps will not replace Braille with octants.

Having this as an option offers the best of both. Cascadia can provide both proper Braille, and the common separated octants used in terminals.

Proposed technical implementation details

Now that Windows Terminal can let each user select to enable or not specific stylistic sets, I think it would be great to have a stylistic set that offers alternate Braille characters.
To make them fit well with the recently introduced separated quadrants and separated sextants, I suggest they be implemented as separated octants, following the same pattern for all separated mosaics.
The example screenshots used in this proposal are using the same separating spaces widths as the separated quadrants and sextants, and the same grid alignments as all other mosaics pseudographics.

Here is an example of the whole quadrants, sextants, octants, and separated variants, with Braille as the separated octants set:

image

The new style would be optional, and easily enabled through the new Font features setting:

image

Adding this feature requires adding separated octants glyphs, and a stylistic set that substitutes the braille glyphs for the corresponding separated octants glyphs.

Extra care must be taken to ensure that the rclt substitutions are also applied after to properly select the separated octants appropriate for the renderer.

@PhMajerus PhMajerus changed the title Feature Request Feature Request: Separated octants mode for Braille characters May 8, 2024
@PhMajerus PhMajerus changed the title Feature Request: Separated octants mode for Braille characters Feature Request: Separated octants mode (stylistic set) for Braille characters May 8, 2024
@PhMajerus
Copy link
Contributor Author

@DHowett
You knew you couldn't add support for stylistic sets in Terminal without getting my hopes up, right?
You can't just add that feature and not leave Cascadia open to a few more changes before locking it up to work on v.Next.

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

No branches or pull requests

1 participant