Support double-width characters #116

Closed
opened 1 year ago by Seirdy · 4 comments
Seirdy commented 1 year ago

Terminals such as st, Alacritty, Kitty, Konsole, and VTE-based terminals support double-width Unicode characters such as emojis and FontAwesome characters, which users often depend on to add icons to their terminals. foot cuts off such glyphs.

Attached is a screenshot of Alacritty and foot to highlight the expected and observed behavior, respectively. I previously raised the same issue in different project (the maintainer changed the issue name).


Version information:

foot version 1.4.4-274-gbb8d937 (Sep 02 2020, branch 'master')

sway version 1.4


Log output:

info: main.c:315: version: 1.4.4-274-gbb8d937 (Sep 02 2020, branch 'master')
info: main.c:322: arch: x86_64/64-bit, 
info: config.c:1831: loading configuration from /home/rkumar/.config/foot/foot.ini
info: main.c:337: locale: en_US.UTF-8
info: wayland.c:1049: DP-2: 2560x1440+0x0@60Hz DELL U2713HM 27.15" scale=1 PPI=111x110 (physical) PPI=111x110 (logical), DPI=108.18
info: wayland.c:1185: requesting SSD decorations
info: fcft.c:196: fcft: 2.2.7-2-gfc9b8b2 (Sep 02 2020, branch 'master')
info: fcft.c:206: fontconfig: 2.13.92
info: fcft.c:212: freetype: 2.10.2
info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-bold.ttf: size=9.50pt/14px, dpi=109.00
info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-italic.ttf: size=9.50pt/14px, dpi=109.00
info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-regular.ttf: size=9.50pt/14px, dpi=109.00
info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-bolditalic.ttf: size=9.50pt/14px, dpi=109.00
info: terminal.c:612: cell width=7, height=18
info: terminal.c:553: using 32 rendering threads
info: wayland.c:646: using SSD decorations
info: fcft.c:586: /home/rkumar/.local/share/fonts/Hasklug/Hasklug Nerd Font Complete.otf: size=9.50pt/14px, dpi=109.00
info: fcft.c:586: /usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: size=72.55pt/109px, dpi=109.00
info: main.c:470: goodbye
Terminals such as st, Alacritty, Kitty, Konsole, and VTE-based terminals support double-width Unicode characters such as emojis and FontAwesome characters, which users often depend on to add icons to their terminals. foot cuts off such glyphs. Attached is a screenshot of Alacritty and foot to highlight the expected and observed behavior, respectively. I previously raised [the same issue](https://github.com/ii8/havoc/issues/16) in different project (the maintainer changed the issue name). ------------------------------------------------------------------------------------- Version information: `foot version 1.4.4-274-gbb8d937 (Sep 02 2020, branch 'master')` `sway version 1.4` ------------------------------------------------------------------------------------- Log output: ``` info: main.c:315: version: 1.4.4-274-gbb8d937 (Sep 02 2020, branch 'master') info: main.c:322: arch: x86_64/64-bit, info: config.c:1831: loading configuration from /home/rkumar/.config/foot/foot.ini info: main.c:337: locale: en_US.UTF-8 info: wayland.c:1049: DP-2: 2560x1440+0x0@60Hz DELL U2713HM 27.15" scale=1 PPI=111x110 (physical) PPI=111x110 (logical), DPI=108.18 info: wayland.c:1185: requesting SSD decorations info: fcft.c:196: fcft: 2.2.7-2-gfc9b8b2 (Sep 02 2020, branch 'master') info: fcft.c:206: fontconfig: 2.13.92 info: fcft.c:212: freetype: 2.10.2 info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-bold.ttf: size=9.50pt/14px, dpi=109.00 info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-italic.ttf: size=9.50pt/14px, dpi=109.00 info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-regular.ttf: size=9.50pt/14px, dpi=109.00 info: fcft.c:586: /home/rkumar/.local/share/fonts/Iosevka Term/ttf/iosevka-term-bolditalic.ttf: size=9.50pt/14px, dpi=109.00 info: terminal.c:612: cell width=7, height=18 info: terminal.c:553: using 32 rendering threads info: wayland.c:646: using SSD decorations info: fcft.c:586: /home/rkumar/.local/share/fonts/Hasklug/Hasklug Nerd Font Complete.otf: size=9.50pt/14px, dpi=109.00 info: fcft.c:586: /usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: size=72.55pt/109px, dpi=109.00 info: main.c:470: goodbye ```
dnkl commented 1 year ago
Owner

Hi, and thanks for taking the time to report this!

This will be a fairly long answer, but don't despair, the ending
isn't all too bleak.

Looking at your screenshots, there are actually two different problems.

Lets start with the easiest one, the emoji. This is a true
double-width character, and foot does handle it correctly.

The problem is the glyph isn't in the primary font, and that the
font size provided by fontconfig (for the fallback font) is based
on line height. You are using a pretty narrow primary font, with
the width of two cells still being less than the line
height. Since emojis are more or less square, it gets cut off.

This is easily fixed by manually adding the emoji font (Noto
Color Emoji, in your case), to foot.ini:

font=Iosevka, Noto Color Emoji:size=8.5

You might have to experiment with the size.

The other issue is with Unicode private usage area
characters. These are treated as single-width characters. This
cannot be changed, for two reasons: one, the terminal and the
client application must use the same widths, or the cursor
position will get "out of sync". Two, the private usage area can
contain anything. While this font has double-width glyphs,
other fonts may very well have single-width glyphs.

And, while it may look like Alacritty supports these, it
doesn't always render these correctly, as seen in the
screenshots.

There are mainly two reason it works better than in
foot. First, Alacritty always re-renders the entire grid (and not
just modified cells). Two, Alacritty allows glyphs to overflow,
or bleed into, neighbouring cells. The latter causes issues like
https://github.com/alacritty/alacritty/issues/118.

Foot used to, sort of, render these glyphs like Alacritty, but
with #21, I decided to
always clip glyphs to their cell(s).

To summarize, the only correct way to deal with these glyphs
is to clip them. Not doing so leads to other issues.

However, this has been a thorn in my eye, so I decided to play
around a bit and see if we can do something that is better than
what we have today. And there just might be. I'll be putting up
an experimental PR shortly, that adds a 'tweak' option that
enables heuristics that just might be good enough. Without
breaking everything else.

Hi, and thanks for taking the time to report this! This will be a fairly long answer, but don't despair, the ending isn't all too bleak. Looking at your screenshots, there are actually two different problems. Lets start with the easiest one, the emoji. This is a true double-width character, and foot _does_ handle it correctly. The problem is the glyph isn't in the primary font, and that the font size provided by fontconfig (for the fallback font) is based on line height. You are using a pretty narrow primary font, with the width of **two** cells still being less than the line height. Since emojis are more or less square, it gets cut off. This is easily fixed by manually adding the emoji font (Noto Color Emoji, in your case), to `foot.ini`: ```conf font=Iosevka, Noto Color Emoji:size=8.5 ``` You might have to experiment with the size. The other issue is with Unicode private usage area characters. These are treated as single-width characters. This cannot be changed, for two reasons: one, the terminal and the client application must use the same widths, or the cursor position will get "out of sync". Two, the private usage area can contain _anything_. While this font has double-width glyphs, other fonts may very well have single-width glyphs. And, while it may _look_ like Alacritty supports these, it doesn't always render these correctly, as seen in the screenshots. There are mainly two reason it works _better_ than in foot. First, Alacritty always re-renders the entire grid (and not just modified cells). Two, Alacritty allows glyphs to overflow, or bleed into, neighbouring cells. The latter causes issues like https://github.com/alacritty/alacritty/issues/118. Foot used to, sort of, render these glyphs like Alacritty, but with https://codeberg.org/dnkl/foot/issues/21, I decided to always clip glyphs to their cell(s). To summarize, the only **correct** way to deal with these glyphs is to clip them. Not doing so leads to other issues. However, this _has_ been a thorn in my eye, so I decided to play around a bit and see if we can do _something_ that is better than what we have today. And there just might be. I'll be putting up an experimental PR shortly, that adds a 'tweak' option that enables heuristics that just might be good enough. Without breaking everything else.
dnkl commented 1 year ago
Owner

info: terminal.c:553: using 32 rendering threads

With this many CPU cores, you could probably reduce the nubmer of workers without noticing a performance drop. If you are resource conservative, that is :)

> `info: terminal.c:553: using 32 rendering threads` With this many CPU cores, you could probably reduce the nubmer of `workers` without noticing a performance drop. If you are resource conservative, that is :)
Poster

Thanks! I get that workarounds to allow PUAs to show glyphs is a bit of a hack, but a significant number of users (there are dozens of us! dozens!) are quite attached, so I appreciate the consideration. I fill in missing features with tmux, so this is really the only thing keeping me from switching to foot right now!

info: terminal.c:553: using 32 rendering threads

With this many CPU cores, you could probably reduce the nubmer of workers without noticing a performance drop. If you are resource conservative, that is :)

Oh yeah, that's a good point. I should probably read through foot(5) properly.

Thanks! I get that workarounds to allow PUAs to show glyphs is a bit of a hack, but a significant number of users (there are dozens of us! dozens!) are quite attached, so I appreciate the consideration. I fill in missing features with tmux, so this is really the only thing keeping me from switching to foot right now! > > `info: terminal.c:553: using 32 rendering threads` > > With this many CPU cores, you could probably reduce the nubmer of `workers` without noticing a performance drop. If you are resource conservative, that is :) Oh yeah, that's a good point. I should probably read through `foot(5)` properly.
dnkl commented 1 year ago
Owner

This is easily fixed by manually adding the emoji font (Noto
Color Emoji, in your case), to foot.ini:

font=Iosevka, Noto Color Emoji:size=8.5

You might have to experiment with the size.

A fleshed out version of this has been added to the wiki: https://codeberg.org/dnkl/foot/wiki#user-content-emojis-get-cur-off

> This is easily fixed by manually adding the emoji font (Noto > Color Emoji, in your case), to foot.ini: > > ``` > font=Iosevka, Noto Color Emoji:size=8.5 > ``` > > You might have to experiment with the size. A fleshed out version of this has been added to the wiki: https://codeberg.org/dnkl/foot/wiki#user-content-emojis-get-cur-off
dnkl closed this issue 1 year 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.