Sixels and Unicode 13.0 blocks interact poorly
I was testing
foot this evening and ran into some weirdness I can't track down to my own misbehavior. Both of these issues can be seen in the
intro demo. I know you're familiar with
notcurses-demo, so I'll skip further introductory text.
I'm running at 80x48, with 10 pixels per column and 21 pixels per row.
The orca ought be on top of everything except the FPS graph (braille-based graph at the bottom), the HUD (rectangular window showing frames/runtime), and the menu (bar along the top). In particular, it ought be visible atop all
introelements. This is the case, except for 8 glyphs in the lower "gaussbar" (the white 8th steps above and below the central text). Numbered 0 to F from left to right, the following glyphs are printed above the sixel:
It's obvious even without the Sixel that the glyphs highlighted above are being drawn differently than the ones marked 'x'. Look at the top "gaussbar", and how everything is even. The bottom is like the big craggly mouth of a prizefighter. All glyphs marked 'x' are aligned to the left of their cells, while the others are centered.
I'll get a screenshot just as soon as I have a compositor installed that supports the necessary extensions, heh.
The blocks being used are:
U+2594 UPPER ONE EIGHTH BLOCK ▔
U+1FB82 UPPER ONE QUARTER BLOCK 🮂
U+1FB83 UPPER THREE EIGHTHS BLOCK 🮃
U+2580 UPPER HALF BLOCK ▀
U+1FB84 UPPER FIVE EIGHTHS BLOCK 🮄
U+1FB85 UPPER THREE QUARTERS BLOCK 🮅
U+1FB86 UPPER SEVEN EIGHTHS BLOCK 🮆
U+2588 FULL BLOCK █
The ones causing trouble are those not introduced by Unicode 13.0. The ones causing trouble with Sixel are those that were introduced in Unicode 13.0.
There are two bugs "co-operating" here, I think. First one is simple; foot doesn't render the newly introduced block characters by itself, but is using font glyphs. This is not intentiontal, but an oversight from my side. This explains why the glyphs themselves look bad.
But why/how does that affect sixels? Let's take a look at a blown up screenshot:
We can see that the glyphs are double width. I'm betting their
wcwidth() is 1 though, causing foot's allow-overflowing-double-width-glyphs "tweak" to kick in.
Why is this a problem? Because of how damage tracking is done; sixels are actually rendered before the cell grid (un-dirtying the cells underneath them). However, the overflowing-double-width-glyphs require us to re-mark the two cells they occupy as dirty, meaning they'll get re-rendered on top of the sixel...
To sum it up, the particular problem we're seeing in notcurses will be fixed by adding the new Unicode 13 block chars to foot's internal set of box drawing chars.
Characters affected by
allow-overflowing-double-width-glyphs will still be a problem, but perhaps a much smaller one. I'll have to think this one through...
causing foot's allow-overflowing-double-width-glyphs "tweak" to kick in.
Sure enough, setting
makes the orca appear on top.
Deleting a branch is permanent. It CANNOT be undone. Continue?