octblitter

[EnronEvolved]

There's a proposal that seems to have been approved by the UTC, that adds a pretty substantial Symbols for Legacy Computing Supplement block, including new block elements and box drawing characters. If notcurses can blit braille, it should be pretty easy to adapt it to use the block octants in the proposal.

The separated sextants and quadrants may have their uses too. What do you reckon?

[dankamongmen]

as far as i'm aware, sextants were added in Unicode 13's Symbols for Legacy Computing, and we're using them in the "sexblitter". quadrants were added long ago (unicode 4?), and we've supported them with "quadblitter" for several years. the discussed "octants", however, could be useful if they're approved.

one problem with this is that while you get the higher resolution--kinda--you can't just go using e.g. eight different colors for an octant glyph. you only ever have two available. the more "pixels" you try to force in there, the more color smudging you might have to do. thus to make use of the "higher-resolution" semigraphics, you lose color fidelity.

if octants get added, i'll add them to the generalized dankblitter.

closing this for now. if they get added, i'll add a new bug. thanks for your interest!

[PhMajerus]

Octants have been approved for publication in Unicode 16.0:
https://www.unicode.org/alloc/Pipeline.html
(The octants are set at U+1CD00 to U+1CDE5, as well as two new required quadrants at U+1FBE6 and U+1FBE7 that are reused for octants.)

You can also track their inclusion in Cascadia Code using the following issue: microsoft/cascadia-code#711

[dankamongmen]

i saw this the other day! awwww shit, awww shit.

as i note above, though, you get more "resolution" but you lose color accuracy. sextants were not nearly as much of an improvement over quadrants as i had hoped, despite being more computationally intensive.

[dankamongmen]

so, i went ahead and merged @eschnett 's PR adding support for NCBLIT_4x2 using Unicode 16 octants, for which he is a champion.

this is not a complete solution, though. for one, we've not yet written code that sets the canoctant capability in terminal properties. without this, NCBLIT_4x2 will never be chosen. that's the biggest thing, i think. also, if any path led to a default choice of NCBLIT_BRAILLE, that ought probably resolve to NCBLIT_4x2.

i'm not sure whether NCBLIT_4x2 should decay to braille if canbraille() is true but canoctant() is not. i'm inclined to think no.

[dankamongmen]

to get a quick look at octants in your terminal, try:

[schwarzgerat](0) $ for i in `seq 0 229` ; do printf "\U$(printf "%x" $(echo "$((i + 0x1cd00))"))" ; done && echo
𜴀𜴁𜴂𜴃𜴄𜴅𜴆𜴇𜴈𜴉𜴊𜴋𜴌𜴍𜴎𜴏𜴐𜴑𜴒𜴓𜴔𜴕𜴖𜴗𜴘𜴙𜴚𜴛𜴜𜴝𜴞𜴟𜴠𜴡𜴢𜴣𜴤𜴥𜴦𜴧𜴨𜴩𜴪𜴫𜴬𜴭𜴮𜴯𜴰𜴱𜴲𜴳𜴴𜴵𜴶𜴷𜴸𜴹𜴺𜴻𜴼𜴽𜴾𜴿𜵀𜵁𜵂𜵃𜵄𜵅𜵆𜵇𜵈𜵉𜵊𜵋𜵌𜵍𜵎𜵏𜵐𜵑𜵒𜵓𜵔𜵕𜵖𜵗𜵘𜵙𜵚𜵛𜵜𜵝𜵞𜵟𜵠𜵡𜵢𜵣𜵤𜵥𜵦𜵧𜵨𜵩𜵪𜵫𜵬𜵭𜵮𜵯𜵰𜵱𜵲𜵳𜵴𜵵𜵶𜵷𜵸𜵹𜵺𜵻𜵼𜵽𜵾𜵿𜶀𜶁𜶂𜶃𜶄𜶅𜶆𜶇𜶈𜶉𜶊𜶋𜶌𜶍𜶎𜶏𜶐𜶑𜶒𜶓𜶔𜶕𜶖𜶗𜶘𜶙𜶚𜶛𜶜𜶝𜶞𜶟𜶠𜶡𜶢𜶣𜶤𜶥𜶦𜶧𜶨𜶩𜶪𜶫𜶬𜶭𜶮𜶯𜶰𜶱𜶲𜶳𜶴𜶵𜶶𜶷𜶸𜶹𜶺𜶻𜶼𜶽𜶾𜶿𜷀𜷁𜷂𜷃𜷄𜷅𜷆𜷇𜷈𜷉𜷊𜷋𜷌𜷍𜷎𜷏𜷐𜷑𜷒𜷓𜷔𜷕𜷖𜷗𜷘𜷙𜷚𜷛𜷜𜷝𜷞𜷟𜷠𜷡𜷢𜷣𜷤𜷥
[schwarzgerat](0) $ 

[dankamongmen]

hrmmmm i'm not sure this reasoning about transparency and a single color are valid for octants:

-// Braille blitter. maps 4x2 to each cell. since we only have one color at                                                         
-// our disposal (foreground), we lose some fidelity. this is optimal for                                                           
-// visuals with only two colors in a given area, as it packs lots of                                                               
-// resolution. always transparent background.                                                                                      
+// generic 4x2 blitter, used for octant and Braille. maps 4x2 to each                                                              
+// cell. since we only have one color at our disposal (foreground), we                                                             
+// lose some fidelity. this is optimal for visuals with only two                                                                   
+// colors in a given area, as it packs lots of resolution. always                                                                  
+// transparent background.  

in fact, i'm pretty sure they're not. i'm trying to remember why this is done for braille, but it's definitely not what we want for octants, where we want to use fore+background color and only be transparent when requested.

so 4x2 is kind of a mix of BRAILLE's projection and 3x2's color selection. i think that's closer to what @eschnett had originally. my bad! i'll fix it up as necessary. if i'm right, ncplayer ought look really weird in 4x2....

[dankamongmen]

• updated NEWS.md, notcurses_visual.3, and ncplayer.1 to mention octant blitter.
• updated ncplayer command line help to mention octant blitter

[PhMajerus]

I think pseudo-pixels characters can be classified into two main categories.

The mosaics are perfect grids with pseudo-pixels of the foreground or background colors, without any gap between them.
Those include full block + space/nbsp, half blocks, quadrants, sextants, and octants.

The separated pseudo-pixels have gaps between them, meaning that not only will they have patterns on a grid, but the grid cells are spaced so the background always also bleeds around the pseudo-pixels making that color much more prominent and filling the gaps regardless of the mosaic pattern provided by the character.
Those include separated quadrants, separated sextants, as well as Braille, which in some fonts are pretty much separated octants.

If you use background colors for separated ones, the shapes become very blocky and usually it just looks better to use the ones without gaps. But if they are used to only render patterns of on pixels over an existing background, they can provide a nice LCD/LED-style image, where pixels are clearly defined, and which sometimes makes sense, such as for VU meters, bar graphs, or just images with less colors but where being able to count the units displayed is beneficial.

If that is the concept, then it makes plenty of sense to have the Braille blitter only use the foreground color, and allow the background color to stay whatever color is best for the UI behind that image. It also means Unicode 16.0 separated quadrants and separated sextants should follow the same foreground-only rendering style, while normal sextants and octants should use both the foreground and background colors like half-blocks and quadrants.

The following issue in Cascadia shows the different kind of renderings that can be achieved with octants and Braille, and clearly shows Braille with background color just shouldn't be used like octants, as the background is too overwhelming compared to the small colored dots:
microsoft/cascadia-code#711

[dankamongmen]

@PhMajerus agreed with your differentiation between "mosaic" and "pseudo-pixel" glyphs.

If you use background colors for separated ones, the shapes become very blocky and usually it just looks better to use the ones without gaps. But if they are used to only render patterns of on pixels over an existing background, they can provide a nice LCD/LED-style image, where pixels are clearly defined, and which sometimes makes sense, such as for VU meters, bar graphs, or just images with less colors but where being able to count the units displayed is beneficial.

this is why the current braille implementation only uses a single color per cell (the foreground color), and the background is always transparent (which can of course be filled in by any cell on an underlying plane).

It also means Unicode 16.0 separated quadrants and separated sextants should follow the same foreground-only rendering style,

yep

while normal sextants and octants should use both the foreground and background colors like half-blocks and quadrants.

yep

so the upshot is: octants ought use a sextant/quadrant-like blitter, where we select two colors via lerping the 4x2 pixel region corresponding to the cell, except in the presence of transparent pixels in the source, which always force transparent background (iirc). that's closer to what @eschnett had originally, but i asked him to change it to a braille-style one, which was my mistake. i'm reimplementing it as a mosaic-style blitter now (and making the mosaic-style blitter generic across all mosaic styles). i think it might then be interesting to do a unified U16 separated quadrants/sextants+braille blitter. if we go this route, we probably deprecate the specifier NCBLIT_BRAILLE, and introduce NCBLIT_SEP_2x2, NCBLIT_SEP_3x2, and NCBLIT_SEP_4x2, where the latter is the replacement of NCBLIT_BRAILLE. i assume braille is why there are no "separated octants", though that's kind of gross and probably not something to rely on.

[dankamongmen]

i'm hoping terminals will directly draw these characters, rather than relying on the font. i think most of them do that with sextants/quadrants. if they do so, we can mark octant support in the heuristics.

i added a check that libc can run wcwidth() on the characters, turning off octant support if not (though nothing turns it on yet).

[dankamongmen]

why aren't U+1FBE6 and U+1FBE7 among the general octants? i feel i'm missing something here.

[PhMajerus]

why aren't U+1FBE6 and U+1FBE7 among the general octants? i feel i'm missing something here.

They are part of a small group of centered quadrants (U+1FBE4 - U+1FBE7) that got added to the original symbols for legacy computing block. Just like other existing patterns already found in half blocks and quadrants, they could be used as it without duplicating them.

Even worse, you'll see some octants patterns are reused 4×4 patterns from the U+1CE90 - U+1CEAF group, which while being in the same Unicode block, are another cluster of characters.

These will probably force you to use a lookup table or special cases in the code to generate octants code points from their pixels patterns.

[dankamongmen]

They are part of a small group of centered quadrants (U+1FBE4 - U+1FBE7) that got added to the original symbols for legacy computing block. Just like other existing patterns already found in half blocks and quadrants, they could be used as it without duplicating them.

sure, it's just the semantics. i wouldn't want to use these in the general quadrant blitter because they require a completely different level of unicode support than the existing quadrants do. i guess if determined to do so, you could have a U16+ quadblitter and a <U16 quadblitter.

These will probably force you to use a lookup table or special cases in the code to generate octants code points from their pixels patterns.

yep, no biggie though

[dankamongmen]

yeah the current octblitter gives braille-like results (but does appear to work):

[dankamongmen]

note that glibc 2.40 does not have unicode 16 support. it does appear to be supported in the upcoming 2.41 release.

[dankamongmen]

heh with unicode 16 i can finally write I�NY

[dankamongmen]

ok, i've got the octtrans[] array built up, so the generic hires blitter runs to completion even with 4x2. i'm doing the other half now.

[dankamongmen]

alright, i think this is done. i just put up #2823 which unifies 3x2 and 4x2

[dankamongmen]

calling this done. there's a case to be made for adding the separated sextants / quadrants, but that's another bug if so. we now have a functioning octblitter using the blocky pseudopixel model, properly slotted among the defaults, and documented. thanks @eschnett and @PhMajerus !

[dankamongmen]

sexblitter on one side, octblitter on the other, eye of gnome in the middle. not much difference, but you'll probably see more in certain kinds of images.

[dankamongmen]

frankly i think we're getting more artifacting in the octblitter. look at those patches against the background in the middle and right. though maybe with better color quantization this goes away.