Custom rendering for box drawing/decoration characters

[cpmsmith]

Is your feature request related to a problem? Please describe.

Depending on line-height and font settings, box-drawing boxes and ASCII art can render with unwanted gaps in between characters, and Powerline/NerdFont symbols can be misaligned to the grid.

Compare to the same setup in iTerm2 with "Use built-in Powerline glyphs" enabled:

Describe the solution you'd like

Special-case the rendering of box drawing and similar characters, ignoring the font used for all other text, in order to make them align perfectly to the grid. For reference, kitty's list of characters for which they have custom rendering can be seen here.

Describe alternatives you've considered

In theory it's possible to patch a font so that its glyphs would line up perfectly with the expected size of cells including line height, similar to the patches suggested to fake line-height support before it was implemented.

Additional context

Many terminal emulators (Kitty, Wezterm, iTerm2, gnome-terminal, etc.) use this strategy, and an Alacritty contributor called it "the only way to solve these issues reliably". Most provide an option to disable this, under different names.

This has been suggested/hinted at across a few different threads, in between mentions of different font rendering issues, or inaccurately describing the gaps as a bug. I'm just opening this issue to track this specific solution as a feature request.

Existing mentions of this idea/issues it would solve:

• ╱ unicode pattern does not display as well as in the terminal #1197
  • That discussion has oscillated between rendering bugs vs this feature request, but it looks like @fredizzimo has been moving toward treating it as the main issue for this feature request, so if he wants, this issue can be considered a duplicate of that one.
• Vertical lines issue #1774
• Odd character/char tile height. Full block char not corresponding to full char tile height. [Uneven Statusline Block] #2295
• Differences between Kitty and Neovide #2375
• Customizing line height #481 (comment)
• Line height issue #1793
• Red line next to character #1225

[Kethku]

I really appreciate this issue as it captures the state of things well. Here are some thoughts and questions that come to mind:

1a. How do we decide how thick to render lines? Maybe we can use the same heuristics that we use for the underline thickness? Im not sure.
1b. Similarly how do we decide what radius to take a curve at. Right now this is handled by the font. Taking control from the font might lead to weird inconsistencies? Not sure
2. This would be a good opportunity to introduce custom divider options. Why limit to the normal powerline ones?
3. If we recognize that a standard box drawing character is being used at the border of a window, we should consider moving the line out to the far edge rather than including a gap there. Such an approach might get close to #2239

[fredizzimo]

This will actually become a high priority issue soon, with the fractional grid rendering support, so I would appreciate if someone could look into this.

It's ok to concentrate on the basics first, where you can assume that the blocks will join at exact pixel coordinates. We need to get it to work where that's not the case as well. But that can be done in a separate PR or as part of the fractional grid support PR.

@Kethku.
1a, 1b. I would make these to configurable as percentages of the block height. I don't think they have much relation to the main font or the nerd fonts variation used. For the underline though, I think that we should actually use https://docs.rs/swash/latest/swash/struct.Metrics.html#structfield.stroke_size, instead of inventing our own.
2. We have to follow the Unicode standard, and also not clash with Nerdfonts. Therefore, I suggest that we primarily support the fully box drawing character set https://en.wikipedia.org/wiki/Box-drawing_characters, and the powerline ones. But if we can, we can support other Nerd fonts and standard unicode characters as well. If we want custom ones, I suggest that we primarily try to get them included in Nerd Fonts.
3. Yes, I think we could allow these kinds of transformations.

Finally, perhaps this could be done as a separate crate that produces svg images. That way it can be used everywhere, independently of which rendering framework is used. Actually, maybe it does not even need to be code, it could just be a set of SVG images, that we can load and render.

Edit: I think it needs to be a library, since I think that scaling svg images won't work properly due to different fonts having different dimensions. But I might be wrong.