Double-width font-awesome/vim-devicon clipped #456
Comments
|
I noticed this too. |
|
I believe this was fixed a couple years ago when stateful renderer went in. |
ychin
added a commit
to ychin/macvim
that referenced
this issue
Jan 21, 2023
This fixes the issue where particularly tall characters will get clipped at the row boundary. This happens because even though a font describes the line height with font metrics, individual glyphs do not have to respect them, and we can see with emoji rendering sometimes they can poke upwards past the line height. Also, it's trivially easy to construct composing characters that become really tall, e.g. "x゙̂⃗", or Tibetan scripts like "ཧཱུྃ". To fix this, we do the following: 1. Remove the explicit clipping call at rendering. 2. Fix partial redraw to not lead to clipping / corruption. This is quite tricky, because let's say we have a character that is tall enough to touch other lines, if those lines are redraw but not the line with the tall char, the redraw will paint over the parts of the glyphs poking through. Alternatively if we redraw the line with the tall chars we also need to expand the redraw region to make sure other lines get repainted as well. To fix this properly, we should do a proper glyph calculation when we receive the draw command before we issue before we call `setNeedsDisplayInRect`, but since right now we only extract glyph info later (during drawRect call), it's too late. We just do the hacky solution by storing a variable `redrawExpandRows` that tracks how many lines to expand for all lines. It's a little hacky since this will affect all lines permanently regardless if they have tall characters or not. The proper fix may come later as an optimization (or when we do hardware rendering via Metal). 3. Re-order the rendering so we have a two pass system, where we first draw the background fill color for all rows, then the text. This helps prevent things like Vim's window split or cursorline from obscuring the text. 4. Add a preference to turn on clipping (old behavior). This helps prevent odd issues with really tall texts (e.g. Zalgo text) making it hard to see what's going on. The preference `MMRendererClipToRow` is not exposed in UI for now as it's a relatively niche. It will be exposed later when we have a dedicated render tab in settings. Note that a lot of these characters only show their full height by doing `set maxcombine=8` because the default (2) is quite low. Fix macvim-dev#456 Part of the fix for macvim-dev#995
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello there,
It seems that double-width icons provided in font sets like font-awesome of vim-devicons are truncated when using the CoreText rendered (without ambiwidth, this option has its own set of inconvenience and is not required in terminal mode).
The issue disappear when using the non-CoreText renderer, although the alignment of the double-width character is completely off.
There is some patch floating around (https://github.com/xusiyuan841028/macvim/commit/27bcfd27d6c3500b6ca27c7387a19b5a8306df17) which solves some of the issues but not all (double-width character in the tabline are still truncated).
The text was updated successfully, but these errors were encountered: