Kitty: Vertically mis-aligned text

Created on 4 Oct 2019  路  25Comments  路  Source: kovidgoyal/kitty

Version: 0.14.6
OS: MacOS 10.14.4

Using Fira Code (v2), the text appears to be oddly aligned to the top instead of the center or baseline. This does not happen in iTerm. I was able to reproduce this on two different machines (but same configs).

I don't have anything special in my kitty.conf. Just setting the font-family to Fira Code.

Screenshots:

Screen Shot 2019-10-03 at 10 08 06 PM

Screen Shot 2019-10-03 at 10 07 37 PM

Here is the vim statusbar in iTerm, where the text is aligned normally.

Screen Shot 2019-10-03 at 10 12 18 PM

Screen Shot 2019-10-03 at 10 12 47 PM

Most helpful comment

My understanding is that adjust_line_height doesn't affect where the glyph is positioned in the cell - sadly the only way to cater for all the whackiness going on with respect to font metrics is by introducing a couple more options like adjust_glyph_position_y, adjust_glyph_position_x and adjust_glyph_scale. I'll take a stab at this eventually unless someone gets in first.

All 25 comments

Post the output of kitty --debug-config

Result of kitty --debug-config

kitty 0.14.6 created by Kovid Goyal
Darwin Rogins-MBP.T-mobile.com 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64
ProductName:    Mac OS X ProductVersion:    10.14.4 BuildVersion:   18E226
Loaded config files: /Users/rfarrer/.config/kitty/kitty.conf

Config options different from defaults:
background            Color(red=0, green=38, blue=53)
color0                Color(red=0, green=56, blue=77)
color1                Color(red=196, green=48, blue=97)
color10               Color(red=156, green=240, blue=135)
color11               Color(red=255, green=204, blue=27)
color12               Color(red=126, green=178, blue=221)
color13               Color(red=251, green=148, blue=255)
color14               Color(red=0, green=255, blue=255)
color15               Color(red=183, green=207, blue=249)
color2                Color(red=127, green=192, blue=110)
color3                Color(red=240, green=142, blue=72)
color4                Color(red=28, green=141, blue=178)
color5                Color(red=198, green=148, blue=255)
color6                Color(red=0, green=204, blue=204)
color7                Color(red=119, green=146, blue=158)
color8                Color(red=81, green=127, blue=141)
color9                Color(red=255, green=90, blue=103)
cursor_blink_interval 0.0
enabled_layouts       ['tall']
font_family           Fira Code Retina
font_size             18.0
foreground            Color(red=230, green=230, blue=220)
macos_option_as_alt   3
symbol_map            {(9211, 9214): 'Meslo LG L DZ for Powerline Regular', (11096, 11096): 'Meslo LG L DZ for Powerline Regular', (57856, 58025): 'Meslo LG L DZ for Powerline Regular', (57504, 57507): 'Meslo LG L DZ for Powerline Regular', (57520, 57535): 'Meslo LG L DZ for Powerline Regular', (57536, 57544): 'Meslo LG L DZ for Powerline Regular', (57548, 57551): 'Meslo LG L DZ for Powerline Regular', (57552, 57554): 'Meslo LG L DZ for Powerline Regular', (57556, 57556): 'Meslo LG L DZ for Powerline Regular', (59136, 59333): 'Meslo LG L DZ for Powerline Regular', (61440, 62176): 'Meslo LG L DZ for Powerline Regular', (9829, 9829): 'Meslo LG L DZ for Powerline Regular', (9889, 9889): 'Meslo LG L DZ for Powerline Regular', (62464, 62632): 'Meslo LG L DZ for Powerline Regular', (63100, 63100): 'Meslo LG L DZ for Powerline Regular', (57344, 57354): 'Meslo LG L DZ for Powerline Regular', (62208, 62227): 'Meslo LG L DZ for Powerline Regular', (58874, 58923): 'Meslo LG L DZ for Powerline Regular', (9984, 10175): 'Meslo LG L DZ for Powerline Regular'}
tab_bar_edge          1
tab_bar_style         separator
window_padding_width  6.0
Added shortcuts:
    alt+right KeyAction(func='resize_window', args=['wider', 1])
    alt+left KeyAction(func='resize_window', args=['narrower', 1])
    alt+down KeyAction(func='resize_window', args=['shorter', 1])
    alt+up KeyAction(func='resize_window', args=['taller', 1])
    shift+super+h KeyAction(func='neighboring_window', args=['left'])
    shift+super+j KeyAction(func='neighboring_window', args=['bottom'])
    shift+super+k KeyAction(func='neighboring_window', args=['top'])
    shift+super+l KeyAction(func='neighboring_window', args=['right'])
Changed shortcuts:
    shift+control+h KeyAction(func='move_window', args=['left'])
    shift+control+j KeyAction(func='move_window', args=['bottom'])
    shift+control+k KeyAction(func='move_window', args=['top'])
    shift+control+l KeyAction(func='move_window', args=['right'])

Dont use Fira Code Retina, just use Fira Code and you should be fine.

I've tried both, Fira Code and Fira Code Retina, both have this problem.

I cannot reproduce with Fira Code, it basically looks likethe cell height calculation is off. Try using adjust_line_height in kitty.conf to compensate.

I have(?) this issue(?) as well and I cannot bring it down to whether or not I just think it's vertically misaligned or I am imaging it, in another issue I posted a screenshot where it appears to be but if you just type xxxxxxxxxx and compare the block cursor it looks centred, if you instead type xxxxxxxxxxh (h on the end) it looks misaligned, I suspect this is more to do with how the xheight(?) of the font itself is set more than anything i.e. it's not actually misaligned but just looks like it. Here xxxx ... is just being used to pad away from PS1. It seems to me the bolder the weight the more xheight it takes up, perhaps try a bolder variant. The $ also has a short inferior tail, notice in the picture below that the bottom-side | of the $ does not touch the red, giving the illusion that the $ is higher than it is. This is Fira itself of course.

I tried adjusting adjust_cell_height with integer and float values ranging from -1.0 < x < 1.0 to -10.0 < x 10.0 and saw no change at all so I am unsure how that setting works.

I also found that the default settings Kitty has for other fonts don't play nice with Fira Code in terms of kerning and line-spacing, so here are the settings I used for Fira that make it look somewhat normal. Text is still very, very slightly fuzzy on an external screen (I know this because Sublime Text 3 is using Fira Code and the font there looks razor sharp but Kitty to the side is as mentioned very, very slightly fuzzy or dimmer looking (both are pure white #FFFFFF).

#: Fonts {{{
  # list supported fonts via `kitty list-fonts`

  font_family      Fira Code Medium
  bold_font        Fira Code Bold
  italic_font      auto
  bold_italic_font auto

  # font size (pts)
  font_size 12

  adjust_line_height -3 # make Fira look normal
  adjust_column_width -1 # make Fira look normal
  adjust_cell_height 0.5 # unsure if this is doing something

  disable_ligatures always
#: }}}

I don't know what is causing this, perhaps just a consequence of some weird rendering or makeup of the font. I am not an expert of even as educated as I'd like to be with fonts or font rendering so I'll leave anyone's guesses to themselves regarding that.

Here's a rather arbitrary and unscientific picture comparison, the red lines are parallel to the top and bottom of the block cursor in kitty, with the cyan lines being parallel to the x. Those purple rectangles on the extreme right represent the exact same distance, so things are indeed centred correctly.

img

The correct setting is adjust_line_height, I misspoke.

I am seeing exactly the same issue but with the FiraCode nerd font. Old version looks like this:

image

New version looks like this:

image

Note:

  • position of N
  • height of cell

Definitely something funky with respect to the metric calculation. Probably also need a way to adjust the baseline.

Dont use patched fonts. Patching breaks them. Use fira code and install the nerd font separately, kitty will pick up the symbols from it automatically.

FWIW, I also think this could be an issue with the font. I saw the same weird misalignment with JetBrains Mono at version 1.0.0. I upgraded to 1.0.3, and the alignment was fixed.

Thanks - yeah I have now tried using non-patched fonts with and without using symbol_map. Still similar issues. I note that rendering in iterm2 looks fine using either the patched version or the unpatched version. As you say it's most probably an issue with the font - potentially the interaction of Freetype and Fira Code when it comes to metrics calculation.

One thing that is probably the easiest to "point at" is the vertical bar symbols in Fira Code. Here is a snap from iTerm2
image
and here it is from Kitty
image

If I get some time, I will see if I can reduce this down to a test against Freetype directly removing Kitty from the equation.

errr, I take it back. I mean CoreText :)

I find that highly unlikely. Kitty will change the vertical alignment of text if it feels it has to. See also #2086. The "problem", to the extent that it's truly a problem and not simply just how Kitty works, is that Kitty cannot draw glyphs which overflow their cells. So, no overflow is ever possible. In #2086 we saw that a lot of things can affect whether or not Kitty feels it has to move the glyph to prevent an overflow, and that those things differ between CoreText and FreeType. However, the most important part of the equation will always be whether any part of the glyph vertically overflows its ascent line. Serious overflows are even resized by Kitty to force them into the cell. See #2294 and #352 for the horizontal case.

IIRC the CoreText backend does a lot less manual adjustment of glyph
positions because CoreText is not as flexible/I am less interested. With
FreeType kitty will do all sorts of adjusting to make the glyph fit well
inside the cell. With CoreText all kitty does is pass the glyph data to
CoreText alongwith glyph positioning that comes from harfbuzz and let
CoreText handle it. If the resulting bitmap does not fit, it rescales
font size and re-renders to force a fit. It is probable that this
re-render is what causes misaligned glyphs. But I dont really know of a
way to avoid it, as the alternative is chopped of glyphs.

Yes, I have been looking at the code as well as the code in iterm2. Essentially it looks like iTerm2 does some scaling and it also sets some different CoreText flags. I did a quick hack in the kitty code to somewhat mimic what iTerm2 does and it seems to look better at first glance. I'll have a look at the harfbuzz data too. I understand you don't have as much interest in CoreText but it's starting to really annoy me so I'll see if I can work something out whilst I still care :)

Regarding chopped off glyphs - do you have a corpus / list of glyphs that you would suggest testing against?

On Sun, Feb 09, 2020 at 06:29:46PM -0800, Michael Welford wrote:

Regarding chopped off glyphs - do you have a corpus / list of glyphs that you would suggest testing against?

It very much depends on the font. In general try wide capitals like
H,M,W

I came here in search of a similar problem. I'm using Operator Mono (ScreenSmart version, I haven't purchased the other families, so can't compare).

Given that the example config mentions using Operator Mono as an example, my impression was that this is _not_ expected behaviour when using Kitty with this font, is that correct?

Screenshot 2020-03-24 at 23 16 35

My config:

font_family      Operator Mono SSm Light
bold_font        Operator Mono SSm Medium
italic_font      Operator Mono SSm Light Italic
bold_italic_font Operator Mono SSm Medium Italic

font_size 12.0

adjust_line_height  2

I've been playing with adjust_line_height, but can't seem to nudge the font to move to the vertical centre (it's slightly closer to the top right now).

My understanding is that adjust_line_height doesn't affect where the glyph is positioned in the cell - sadly the only way to cater for all the whackiness going on with respect to font metrics is by introducing a couple more options like adjust_glyph_position_y, adjust_glyph_position_x and adjust_glyph_scale. I'll take a stab at this eventually unless someone gets in first.

More examples.

Here I'm using "DroidSansMono Nerd Font"

Screenshot 2020-05-23 at 23 27 06

Same problem here. I think it happens with several fonts but with Fira Code (the one in the screenshots below) is particularly obvious. This happens with all versions of kitty for me.

kitty.conf:

font_size 16
font_family      Fira Code

kitty:
Screenshot 2020-06-22 at 14 03 02

Alacritty:
Screenshot 2020-06-22 at 14 32 11

Terminal (ignore the colors):
Screenshot 2020-06-22 at 14 29 15

See the PR above - this should allow some options so you can tweak exactly what it looks like / where the glyphs are positioned inside the cell.

The problem seems to be the sizing and position of the glyphs _inside_ the cell so no manner of cell transformations (as opposed to glyph) would have helped.

So with the above PR, the settings that I am using are (note that I use a different font for the italic):

font_family Fira Code Regular
italic_font Hack Italic
bold_font Fira Code Medium
bold_italic_font Hack Bold Italic

macos_adjust_glyph_scale 0.05
macos_adjust_glyph_y -4.0
macos_adjust_glyph_x -1.0
macos_thicken_font 0.55

font_size 15.0

adjust_column_width 95%
adjust_line_height 95%

I have the issue on macos with Fira Code 5.2 and kitty 0.19.1
Is it a kitty issue or a font one ?

Screenshot 2020-10-06 at 22 00 30

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Askannz picture Askannz  路  3Comments

Jomik picture Jomik  路  4Comments

drandreaskrueger picture drandreaskrueger  路  4Comments

JJGO picture JJGO  路  3Comments

hdriqi picture hdriqi  路  3Comments