Unicode 16.0 support

[hpjansson]

We need to add support for new Unicode 16.0 legacy symbols, chiefly:

• Large type symbols (@PhMajerus wrote a great overview in Feature Request: Large Type Pieces (Unicode 16.0) microsoft/cascadia-code#709).
• Octants (see similarly great Feature Request: Octants (Unicode 16.0) microsoft/cascadia-code#711).

Large type builtins will probably require manual definitions, but those for octants can be generated at runtime. We need new tags CHAFA_SYMBOL_TAG_OCTANT/octant and CHAFA_SYMBOL_TAG_LARGETYPE/largetype.

We may want to extend the coverage of the legacy tag, but it may be wise to hold off on this until terminal/font support is more widespread.

It'd also be a good idea to test our total coverage with Cascadia Code and look for any obvious gaps.

[PhMajerus]

I don't think the Large Type Pieces make sense for your project, unless I missed some text rendering feature besides the image conversions. The large type are really designed to build large text and their weight and exact design may differ from one font to another, so I really wouldn't use them in a bitmap to ANSI/VT converter.
Try the following if you want more details than in my Cascadia feature request, the following document is more complete: curl https://raw.githubusercontent.com/PhMajerus/Documents/main/HowTos/HowTo%20Large%20Type%20Pieces.txt (from a terminal using a font that supports large type pieces).

On the other hand, octants are definitely something you'll want to support in a bitmap to ANSI/VT converter. Here is a comparison of all the pseudo-pixels mosaics:

These are half-blocks, quadrants, sextants, octants, separated quadrants, separated sextants, and braille.

Another set of characters coming in Unicode 16.0 that you'll want to take advantage of and are predictable regardless of the font are the sedecimants and eights sets, they add some 4×4 and 8×8 patterns.
They don't provide all the patterns possible, but adding them to improve the resolution would be great:

curl https://raw.githubusercontent.com/PhMajerus/Documents/main/CheatSheets/More%20blocks%20tables.txt

[hpjansson]

I don't think the Large Type Pieces make sense for your project, unless I missed some text rendering feature besides the image conversions. The large type are really designed to build large text and their weight and exact design may differ from one font to another, so I really wouldn't use them in a bitmap to ANSI/VT converter.

Well - Chafa is kind of two-pronged. On one hand (and by default) it does straight MSE minimization to code points that look similar across terminals and fonts. On the other, it also supports alternative symbol sets and escape sequences for more traditional/artistic flavors, e.g. ASCII, some CJK, and custom fonts. I'd like to push further in both directions.

There's a lot of interesting research on structural character art rendering - see #150 for examples and ideas. Some of those could benefit from a greater selection of "imperfect" connective glyphs.

Try the following if you want more details than in my Cascadia feature request, the following document is more complete:

On the other hand, octants are definitely something you'll want to support in a bitmap to ANSI/VT converter. Here is a comparison of all the pseudo-pixels mosaics:

Another set of characters coming in Unicode 16.0 that you'll want to take advantage of and are predictable regardless of the font are the sedecimants and eights sets, they add some 4×4 and 8×8 patterns. They don't provide all the patterns possible, but adding them to improve the resolution would be great:

Brilliant - definitely adding support for these!

[PhMajerus]

I've been thinking about your idea of using all possible characters by loading fonts and analyzing the glyphs.
Did you already include color emojis in your renderers?
This could work like those pieces of art creating a large picture using a patchwork of smaller pictures. Emojis could provide some shape and colors contributing to a larger image.

This example only uses hearts emojis for their colors as pseudo-pixels:

It doesn't provide any benefit over VT colors in a terminal, but works in plain-text:
🧡🧡🧡🧡🧡🧡🧡🧡🧡🧡🧡🖤🖤🖤🖤🖤🖤🧡🧡🧡
🧡🧡🧡🧡🧡🧡🧡🧡🧡🖤🖤🖤🖤🖤🖤🖤🖤🖤🧡🧡
🧡🧡🧡🧡🧡🧡🖤🖤🖤🖤🖤🖤🖤🖤🖤🖤🖤🖤🧡🧡
🧡🧡🧡🧡🧡🖤🖤🖤💙💙🖤🖤🖤🖤🖤🖤🖤🖤🖤🧡
🧡🧡🧡🖤🖤🖤🖤🖤💙🩵💚🩶💙🖤🖤🖤🖤🖤🖤🧡
🧡🧡🖤🖤🖤🖤🖤🖤💙🩵🩵💛💚🩵💙🖤🖤🖤🖤🧡
🧡🧡🖤🖤💜🖤🖤🖤🖤🩵🩵🩵🩵💙🩶🩵💙🖤🤎🧡
🧡🖤🖤🖤🖤🖤🖤🖤🖤🖤💙🩵🩵💜💜🩷🩵💙🧡🧡
🧡🖤🖤🖤💜💜💜💜💜💜🖤🖤💙💜💙💜🩶🩵🧡🧡
🧡💜🖤🖤💜💜💜💜💜💜🩷🩷🖤🖤🖤💜🩵🩵🧡🧡
🤎💜💜🖤💜💜💜🩷💜🩷🩷🩷💜💜🩷💜🖤💙🧡🧡
🖤🩷🖤💜💜💜💜🩷💜🩷🩷🩷🖤🖤🩷🩷🩶🧡🧡🧡
🤎💜💜💜💜💜💜💜💜💜🩷🩷🩷🩷🩷🩷🩷🧡🧡🧡
🧡💜💜💜💜💜💜💜💜💜💜🩷🩷💜🖤🩷🩷🧡🧡🧡
🧡🖤💜🖤💜💜💜💜💜💜💜🖤🩷🩷🩷🩷🩷🧡🧡🧡
🧡🤎🖤💜💜💜💜💜💜💜🖤🖤💜🖤💜🩷🩷🧡🧡🧡
🧡🧡🖤💜💜💜💜💜🖤🖤🖤🖤🖤🖤🖤💜🩶🧡🧡🧡
🧡🧡🤎🩷💜💜💜💜💜💜🖤🖤🖤🖤🖤🤎🧡🧡🧡🧡
🧡🧡🧡🩷💜💜💜💜💜💜🖤🖤🖤🖤🤎🧡🧡🧡🧡🧡
🧡🧡🖤🩷💜💜💜💜💜💜🖤💜💜💜🧡🧡🧡🧡🧡🧡

You could achieve something more detailed by using all the emojis patterns and colors to do this at a higher resolution, and it would still work in plain-text.

[hpjansson]

Yes - I kept the door open to this in the API, so when implemented, you will be able to add multicolor glyphs while remaining backwards compatible.

See chafa_symbol_map_add_glyph() - it takes a number of pixel formats, although currently it's rendered to mono bitmaps internally. The internals will need some work.