Sixels and Unicode 13.0 blocks interact poorly #471

Closed
opened 6 months ago by dankamongmen · 6 comments

I was testing notcurses-demo with 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.

  1. 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 intro elements. 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:

                          x12x456xx9ABxDEx
    
  2. 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.

I was testing `notcurses-demo` with `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. 1) 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 `intro` elements. 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: x12x456xx9ABxDEx 2) 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.
Poster

This is foot 1.7.2 from the AUR. I'm specifying Hack:size=9 in my .config/foot/foot.ini.

This is foot 1.7.2 from the AUR. I'm specifying `Hack:size=9` in my `.config/foot/foot.ini`.
Owner

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:

https://codeberg.org/attachments/91c3675b-61c0-4c57-b8c5-5cd4789ed17c

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...

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: ![https://codeberg.org/attachments/91c3675b-61c0-4c57-b8c5-5cd4789ed17c](https://codeberg.org/attachments/91c3675b-61c0-4c57-b8c5-5cd4789ed17c) 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](https://codeberg.org/dnkl/foot/wiki#user-content-nerd-fonts-powerline-font-awesome-doesn-t-work) "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...
Owner

causing foot's allow-overflowing-double-width-glyphs "tweak" to kick in.

Sure enough, setting

[tweak]
allow-overflowing-double-width-glyphs=no

makes the orca appear on top.

> causing foot's allow-overflowing-double-width-glyphs "tweak" to kick in. Sure enough, setting ``` [tweak] allow-overflowing-double-width-glyphs=no ``` makes the orca appear on top.
dnkl added the
bug
label 6 months ago
Owner

#473 implements the glyphs used by the intro, and a couple more.

We still don't render the entire "Symbols for Legacy Computing" block. I'll open up a separate ticket to track that. Not sure we want/need to implement them all. @dankamongmen input on this would be greatly appreciated :)

https://codeberg.org/dnkl/foot/pulls/473 implements the glyphs used by the intro, and a couple more. We still don't render the _entire_ "Symbols for Legacy Computing" block. I'll open up a separate ticket to track that. Not sure we want/need to implement them all. @dankamongmen input on this would be greatly appreciated :)
Owner

We still don't render the entire "Symbols for Legacy Computing" block. I'll open up a separate ticket to track that. Not sure we want/need to implement them all. @dankamongmen input on this would be greatly appreciated :)

Tracked in #474

> We still don't render the entire "Symbols for Legacy Computing" block. I'll open up a separate ticket to track that. Not sure we want/need to implement them all. @dankamongmen input on this would be greatly appreciated :) Tracked in https://codeberg.org/dnkl/foot/issues/474
Owner

Closing in favor of #475 and #474

Closing in favor of https://codeberg.org/dnkl/foot/issues/475 and https://codeberg.org/dnkl/foot/issues/474
dnkl closed this issue 6 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.