WIP: Consider scaling oversized glyphs

[lread]

Extracted from #2

Problem

Although we do now show Unicode characters #18, some character glyphs do not display ideally for command line customizations like powerlevel10k.

Here's an example from of a powerlevel10k using their recommended MesloLGS NF font (NF = Nerd Font, there's a bunch of them that are typically popular monospace fonts with special glyphs added). I chose a larger font size to allow us to see more detail of any oddities.

clojure -M:membrane.term --font-family 'MesloLGS NF' --font-size 20

<Insert screenshot here, after PR for #2 merged>

Out of Scope

Emoji glyphs require special handling and are covered in #20.

Analysis

Sample Glyphs

Some fonts, for whatever reason, contain glyphs that exceed the font's advanced width, line height, or both.

Let's use the lovely opentype.js glyph inspector to showcase some examples from the MesloLGS NF font.

The following glyph is sometimes used in powerlevel10k prompts:

Notice how it crosses above the ascender and below the descender lines.

The Apple glyph is also used in the powerlevel10k prompt:

It's height is fine, but its width exceeds the font's advance-width.

Some glyphs exceed both line-height and advance-width:

Some glyphs don't exceed a height or width but extend across the font's cell boundaries. Line drawing glyphs are good examples of these:

What do other terminals do?

Terminals handle these glyphs with varying degrees of success.

• iTerm2 does a pretty good job, but does exhibit some oddities at different font sizes.

• I've noticed that the Countour terminal developers have taken a strong interest in displaying glyphs cleanly. They seem to, by default, take over the drawing of box, line, and other characters for "pixel perfect" rendering.

• The kitty terminal describes its treatment of special symbols:

  The number of cells a unicode character takes up are controlled by the unicode standard. All characters are rendered in a single cell unless the unicode standard says they should be rendered in two cells. When a symbol does not fit, it will either be rescaled to be smaller or truncated (depending on how much extra space it needs). This is often different from other terminals which just let the character overflow into neighboring cells, which is fine if the neighboring cell is empty, but looks terrible if it is not.

  Some programs, like powerline, vim with fancy gutter symbols/status-bar, etc. misuse unicode characters from the private use area to represent symbols. Often these symbols are square and should be rendered in two cells. However, since private use area symbols all have their width set to one in the unicode standard, kitty renders them either smaller or truncated. The exception is if these characters are followed by a space or empty cell in which case kitty makes use of the extra cell to render them in two cells.

Strategy

I've experimented with scaling large glyphs to our monospace cell dimensions while preserving the glyph's aspect ratio. This looked promising but I discovered it messed with line drawing glyphs enough to make them not line up.

Next Steps

• I'll update this text in place as I learn more.
• I'll try to reach out to the Countour terminal team to learn more about their general scaling approach. A little flowchart would be helpful.