Rendering for the remaining unicode block octant characters

[travisahumphreys]

hey, i've been messing around with block octant unicode characters and ran into an alignment issue with a few of them.

the single-corner octant characters - the ones encoded as "block elements" in the Legacy Computing Supplement (e.g. U+1CEA8 LEFT HALF UPPER ONE QUARTER BLOCK (stand-in for BLOCK OCTANT-1), U+1CEAB RIGHT HALF UPPER ONE QUARTER BLOCK (stand-in to BLOCK OCTANT-2), and the bottom equivalents) - render misaligned when placed next to characters from the main octant range (U+1CD00–U+1CDE5).

it looks like kitty custom-draws the U+1CD00 block mosaic range but these characters fall through to the font renderer instead. i verified in fontforge that the font glyphs have identical advance width (1200) and side bearings (128) to the correctly-rendered octants, so the font metrics aren't the problem - it's the two different rendering paths producing different results.

this lines up with what https://arewelegacycomputingyet.com/ shows: kitty is at 100% for "Block mosaic" in the supplement but 0% for "Block elements."

to reproduce

print an octant-1 (U+1CEA8) to the right of an octant-2 (U+1CEAB):

printf '\n\t\U1CEAB\U1CEA8\n'

the two quarter blocks should tile seamlessly to form the upper half of the cell, but there's a visible gap/offset between them. compare with two instances of BLOCK OCTANT-12 (U+1FB82) which merge into a contiguous shape:

printf '\n\t\U1FB82\U1FB82\n'

printing a properly rendered octant next to one of the problem-characters makes it more obvious:

printf '\n\t\U1FB82\U1CEA8\n'  # octant-12 followed by an octant-1

screenshot

expected behavior / conclusion

these block element codepoints should be included in kitty's custom drawing routine alongside the main octant range so all octant characters render consistently and tile without gaps.

the affected characters are the ones representing single octant positions at the four corners (positions 1, 2, 7, 8 in the 2×4 grid) that are encoded outside the main U+1CD00 range. multi-octant combinations that include those corners render fine because they're in the custom-drawn range.

[kovidgoyal]

Fixed in #9850 havent tested it, leave that to you, but its pretty trivial code.