Jonathan Coxhead jonathan.coxhead at
Mon Jan 24 00:04:52 CST 2022

   This is very fine! I'm very pleased to see work like this. My own
interest led me to write a script to use the light box, heavy box and
double box characters to make pretty tables out of CSV files, like this:

╭─┬─╮  ┏━┳━┓  ┌─┬─┐  ╔═╦═╗
│1│2│  ┃1┃2┃  │1│2│  ║1║2║
├─┼─┤  ┣━╋━┫  ├─┼─┤  ╠═╬═╣
│3│4│  ┃3┃4┃  │3│4│  ║3║4║
╰─┴─╯  ┗━┻━┛  └─┴─┘  ╚═╩═╝

   One thing I noticed is that your code is built around using the 1/8
block characters, but the BLOCK DIAGONALS (sorry, don't mean to shout) are
supposed to work with the SEXTANT (1/6) characters. Not an insurmountable
problem, I'm sure.

   Thanks for posting!

On Sat, 22 Jan 2022 at 19:12, Joao S. O. Bueno via Unicode <
unicode at> wrote:

>>    I was also wondering idly if anyone has any practical uses for the
>> legacy computing characters, specifically the ones with "BLOCK DIAGONAL" in
>> the name. They look tantalisingly as though they must be good for
>> something, but I don't know what it could be—
> I have those on my roadmap.  :-)
> I am author to the "terminedia" framework for Unicode Art and terminal
> based applications -
> the code enables one to use a drawing API to draw with characters, anyone,
> but including
> full block (\U2588) as pixels, and then uses 1/4 block characters for "hi
> resolution",
> with each character block being able to convey 4 pixels. There is a
> hackish mode
> with braille characters, with 8 pixels/block, and, few months after the
> legacy
> computer characters were added and generally available, I added support
> for the 1/6 block sextant characters as a drawing mode.
> The other legacy characters currenntly have no better support in the
> project than most emojis - but the "BLOCK DIAGONAL" in specific are
> in my roadmap: when I get to implement the "1/2 pixel per block" drawing
> mode,
> taking two character blocks per "pixel", I will add a transform to fill in
> corners
> with the appropriate "BLOCK DIAGONAL" characters to make curves
> "smooth'.
> I use a similar approach for using the line/table drawing characters now
> ("HEAVY QUADRUPLE DASH *", for example): one draws boxes and lines
> with fullblocks, apply a transform, and have the characters replaced by
> the apropriate frame drawing chars.
> Unfortunately, I am not getting a lot of time to put in the project
> over the last few months, and I am currently in the task of
> improving the usability of the text-based widgets, so that
> the project can be used for real-world apps.
> The project is at
>  the main gap is documentation. It installs along with
> some example scripts, and there is a separate project that uses
> it, and can be used to draw interactively on the terminal using the above
> mentioned "pixel" modes -
> (installable with `pip3 install --user terminedia-paint`, currently no
> Windows support,
> and on MacOS it needs a terminal program that supports full color ANSI
> codes. )
> And finally - yes, I'd also greatly appreciate proper responses for your
> main query -
> as being able to introspect the full unicode charset and make developers
> life
> easier when dealing with Unicode is one of the project's missions.
> I
> On Sat, 22 Jan 2022 at 06:31, Asmus Freytag via Unicode <
> unicode at> wrote:
>> On 1/21/2022 6:40 PM, Markus Scherer via Unicode wrote:
>> I would show all format controls (gc=Cf
>> <>)
>> with a code. A few might have a non-empty default glyph, but it's probably
>> not worth getting more precise.
>> Best regards,
>> markus
>> The code charts use special glyphs for these, for those users who don't
>> memorize hex codes.
>> A./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list