-
-
Notifications
You must be signed in to change notification settings - Fork 924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vertically mis-aligned text #2022
Comments
Post the output of kitty --debug-config |
Result of 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 I tried adjusting 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).
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 |
The correct setting is adjust_line_height, I misspoke. |
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. |
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 |
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? My config:
I've been playing with |
My understanding is that |
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):
|
Any updates on this? Kitty is the only emulator where this happens |
Looks like baseline calculation in cell metrics is quite off. Lines 340 to 345 in 6179cfc
Using CoreText's method the cell height can be quite bigger than ascent + descent .I managed to solve this issue (or at least make it look much better) by doing something like this
|
On Tue, Apr 20, 2021 at 06:11:24AM -0700, Camouflager wrote:
Looks like baseline calculation in cell metrics is quite off. https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/kitty/core_text.m#L340-L345
Using CoreText's method the cell height can be quite bigger than `ascent + descent`.
I managed to solve this issue (or at least make it look much better) by doing something like this
```
*baseline = (unsigned int)(*cell_height - self->descent);
```
That will just work for your particular case. As is the case with most
Apple software, there is no good API to calculate this. If you have a
general purpose solution that is better than the existing code, I am all
ears.
|
Good point. I'll just post my workaround here for what it's worth diff --git a/kitty/core_text.m b/kitty/core_text.m
index b3065f6..c5c02af 100644
--- a/kitty/core_text.m
+++ b/kitty/core_text.m
@@ -332,10 +332,7 @@
}
}
*cell_width = MAX(1u, width);
- *underline_position = (unsigned int)floor(self->ascent - self->underline_position + 0.5);
*underline_thickness = (unsigned int)ceil(MAX(0.1, self->underline_thickness));
- *baseline = (unsigned int)self->ascent;
- *strikethrough_position = (unsigned int)floor(*baseline * 0.65);
*strikethrough_thickness = *underline_thickness;
// float line_height = MAX(1, floor(self->ascent + self->descent + MAX(0, self->leading) + 0.5));
// Let CoreText's layout engine calculate the line height. Slower, but hopefully more accurate.
@@ -356,6 +353,9 @@
CGFloat line_height = origin1.y - origin2.y;
CFRelease(test_frame); CFRelease(path); CFRelease(framesetter);
*cell_height = MAX(4u, (unsigned int)ceilf(line_height));
+ *baseline = (unsigned int)(*cell_height - self->descent);
+ *strikethrough_position = (unsigned int)floor(*baseline * 0.65);
+ *underline_position = (unsigned int)floor(*cell_height - self->descent - self->underline_position + 0.5);
#undef count
} |
Hello friends. I was playing around with RenderDoc this evening while working on MFEKglif, and discovered that one of its images provides a perfect way for users to understand how Kitty works. As has been stated many times, You see…Your graphics card sees…MeshQuadsPipelineAs you can see from the quads, we draw one quad at a time. Here are our sprites for the frame above: You might notice some of these sprites seem to cover more than one quad, but they do not. They're ligatures, drawn in pieces. That works because they're an exact multiple of the width of one quad, and don't overflow. So…case closed. @kovidgoyal is obviously right—to change Kitty to be able to overflow would mean a fundamental change to its very core. That's too time consuming for such a small marginal benefit like being able to overflow, so we aren't able to. Hope this helped someone visualize |
I finally found an API to query CoreText for the adjusted baseline position. Pushed a fix based on that. Please test. In particular, also check if the underline position is correct, I am not sure whether it should be calculated as round(float_baseline + float_offset) or round(round(float_baseline) + float_offset) And you can have kitty output detailed debugging info on all the various types of font metrics by running it with --debug-rendering |
I tried it out - didn't seem to fix the problem with Fira Code for me, this is what I am seeing: vs (old version of Fira code) Output from --debug-rendering:
|
And what metrics are printed out with --debug-rendering? |
Not sure you saw it but I posted it above just as you wrote that comment.
|
Looks correct to me. CoreText has added seven pixels to the line height
specified by the font, giving a line height of 44 pixels. And it renders
the baseline at 35 pixels, whereas the font metrics would want it at
27.6 pixels from the top. So CoreText would render the baseline at ~ 80%
of cell height, which is what kitty is doing in your screen shot as
well.
The metrics from the font would give a line height of 37 pixels and
baseline of 28 pixels or ~ 75% of cell height. I could have kitty use
those metric instead, but then its rendering would not match that of
CoreText, which Apple users assure me is an extremely desirable thing.
|
Riiiight - I am following you now. I guess it might be nice to try seeing what it looks like using the font metrics or alternatively rendering the glyph in the centre (3.5px from the top) - but I'll give that a go in my own time if you can't be bothered. Thanks for the update 👍 |
That's a different issue, there isnt vertical space in the cell for the diacritics which is causing the glyphs to be pushed down. |
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:
Here is the vim statusbar in iTerm, where the text is aligned normally.
The text was updated successfully, but these errors were encountered: