Closed PhMajerus closed 2 months ago
Another small demonstration of why octants are interesting for lines-based drawings (vectors, fonts, monochrome images,…). Here is the same text rendered as half-blocks with grayscale anti-aliasing using VT colors, and as plain-text octants taking advantage of their increased pseudo-pixels resolution. In each case the text has the same characters cells height, fitting 3 lines.
I believe an external utility could even replace Braille with Octants on the fly, making it possible to pipe existing apps using Braille without modifying them. This makes the implementation of octants even more interesting, but is outside the scope of this feature request.
Off-topic, but as a coding practice, I made a little snippet to generate Unicode Octant characters from the given bits (0-255): https://gist.github.com/Explorer09/1da382e4b1cf3bf2e8009e60836af70b https://gitlab.com/-/snippets/3710003
Description of the new feature
Many modern command-line apps are using Braille characters as pseudo-pixels to render graphics in the terminal.
They provide a 2×4 grid per character, using them as semigraphic mosaics. However, Braille is not a good solution because the symbols are using discrete dots, which makes the on and off pseudo-pixels unbalanced, and they always have space between symbols and between lines, so when using a group of cells to render a graphic, the grid of pseudo-pixels is not a regular grid:
Some terminals modify the Braille characters to space the dots evenly and avoid spaces between characters and lines, but that breaks their original intended use.
Unicode 16.0 will provide a better solution, it includes octants, which, just like the half-blocks and quadrants, provide a regular mosaic pattern designed to be used as pseudo-pixels:
Octants provide the highest resolution that can be achieved currently without using graphical extensions such as Sixels or ReGIS. They can also be combined with VT control sequences to generate color images:
These would not be possible using Braille or other non-mosaic characters, as they need foreground and background colored pseudo-pixels to completely fill their respective parts of the mosaic grid to work properly without background color bleeding:
This request replaces a previous suggestion to modify the Braille characters to achieve the same visual result: #647
Proposed technical implementation details
In January 2022, Unicode approved a new set of legacy computing characters, that includes those octants, to be part of Unicode 16.0.
The octants are set at
U+1CD00
toU+1CDE5
, as well as two new required quadrants atU+1FBE6
andU+1FBE7
that are reused for octants.Cascadia should include the set of octants so apps can start moving from Braille to octants. This represents 238 glyphs (there are 256 mosaic patterns, but some already exist as part of half-blocks and quadrants).
Since octants do not duplicate patterns already available as full-block, half-blocks, and quadrants, all pseudo-pixels semigraphic characters must be designed using a unified set of coordinates. This may require fixing some of the existing characters, such as explained in #644.
I believe an external utility could even replace Braille with Octants on the fly, making it possible to pipe existing apps using Braille without modifying them. This makes the implementation of octants even more interesting, but is outside the scope of this feature request.