Unicode char render too small

[glepnir]

Describe the bug

I used some unicode chars ❶❷❸❹❺❻❼❽❾❿，Iterm2 render it normal,but kitty render it too small.

To Reproduce
Steps to reproduce the behavior:

1. use my plugin https://github.com/hardcoreplayers/vim-buffet in vim/neovim

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Environment details
OS: Name and version of operating system(s)

kitty 0.18.1 (4309e2371d) created by Kovid Goyal
Darwin stephendeiMac.local 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
ProductName:    Mac OS X ProductVersion:        10.15.5 BuildVersion:   19F101
Loaded config files: /Users/stephen/.config/kitty/kitty.conf

Config options different from defaults:
adjust_column_width                -1
background                         Color(red=27, green=43, blue=52)
bold_font                          Operator Mono Lig Medium
bold_italic_font                   Operator Mono Lig Medium Italic
color1                             Color(red=255, green=85, blue=85)
color10                            Color(red=80, green=250, blue=123)
color11                            Color(red=240, green=250, blue=139)
color12                            Color(red=189, green=146, blue=248)
color13                            Color(red=255, green=120, blue=197)
color14                            Color(red=138, green=233, blue=252)
color2                             Color(red=80, green=250, blue=123)
color3                             Color(red=240, green=250, blue=139)
color4                             Color(red=189, green=146, blue=248)
color5                             Color(red=255, green=120, blue=197)
color6                             Color(red=138, green=233, blue=252)
color7                             Color(red=187, green=187, blue=187)
color8                             Color(red=84, green=84, blue=84)
color9                             Color(red=255, green=84, blue=84)
copy_on_select                     clipboard
cursor                             Color(red=124, green=172, blue=74)
cursor_blink_interval              0.0
font_family                        Operator Mono Lig Book
font_size                          17.0
foreground                         Color(red=248, green=248, blue=242)
italic_font                        Operator Mono Lig Book Italic
macos_quit_when_last_window_closed True
macos_titlebar_color               455816194
mouse_hide_wait                    3.0
selection_background               Color(red=68, green=71, blue=90)
selection_foreground               Color(red=30, green=31, blue=40)
tab_bar_style                      hidden

Additional context

Can reproduce with kitty --config NONE

[kovidgoyal]

That's a bug in iTerm, it appers to be rendering it as an emoji in two
cells. As per the unicode standard, it is not an emoji https://unicode.org/Public/emoji/13.0/emoji-sequences.txt

[glepnir]

Aha , but it looks like good right? I check the alacritty, its also same as iterm2. So Is it possible that kitty render it like alacritty and iterm2?

[kovidgoyal]

Looks good is subjective and if you want kitty to render it like that, use the adjust option, that's why it is provided.

[kovidgoyal]

oh sorry, responding to wrong bug report

[kovidgoyal]

Its supposed to be rendered in a single cell, rendering it in two cells will actually break things, looking good is less important than actually being standard compliant. What can be done is implementing a hack similar to what kitty does for PUA charcters, where if the character is followed by a space, kitty uses two cells to render it, while the character itself still occupies one cell. However this is a hack, and I am not very keen to implement it.

[glepnir]

First of all, I respect your decision，I check the this behavior in alacritty iterm2 default terminal in mac. there are has same behavior. However, kitty is different from them, so it is a good decision to align with them?

[kovidgoyal]

Sorry but X terminals doing the wrong thing is not an argument for kitty joining them.

[glepnir]

Hmm. ok. Is it reasonable to set an option to enable this render hack?

[glepnir]

I think it's not a bug. because i check some terminals in linux and macos. they are has a same behavior.

[glepnir]

I found this unicode char code https://unicode-table.com/en/sets/arabic-numerals/

[kovidgoyal]

Again X terminals doing something does not make it right. You want to argue its a bug show me some standard that says those characters should be rendered in two cells. In fact on my system even the system libc implementation of wcwidth says the width of U+2776 is 1

[kovidgoyal]

And I have no idea what terminal you are testing on, in both gnome-terminal and xterm, they are rendered in a single cell.

[glepnir]

yes its same. Does it render as expected in your terminal ? this is my test.

[kovidgoyal]

Yeha it looks bigger in gnome-terminal because gnome-terminal is bleeding it into the next cell. Try this

printf '\u2776a'

see how the circle overlaps the a. That is a rendering bug, in kitty, the circle will be scaled down to fit and not overlap.

[glepnir]

It will look like this .

[kovidgoyal]

Exactly, rendering bug.

[glepnir]

Perhaps this is the design of these terminals in order to better display these numbers unicode? Maybe we can collect everyone's opinions?

[kovidgoyal]

No its not design. It's a bug. A proper design would be to only overflow when the next character is a space. This is the solution I refered to in my previous post. And its a five line patch to implemet it in kitty.

[glepnir]

Aha ok . I will rewrite my plugin to display vim buffer number.

[glepnir]

Wow , it works fine. Thanks!