Closed EdmundsEcho closed 2 years ago
This is over-kill, but when the latest version of the app did not solve the problem, I thought that I would try to get a better handle of the problem. Perhaps I might succeed at articulating the issue with enough precision such that it is easier to find a solution. This may include identifying a fault in how I understand the problem.
The following closed issue discusses ligatures vs "combining" characters: #3795
The stream concludes by stating we should track the support for ligatures: #55
Per the following from CS department at University of Virginia, there is an important distinction between ligatures and the "emojis" that are the subject of my issue. They are each a single "glyph", they are each encoded using two UTF8 "code-points", however they are different sizes and require different capabilities to render correctly. More specifically, emojis render like any other standard "glyph" in that they consume a single "screen column". This is not the case for ligatures; they require between one and two "screen columns".
Term | Definition | Motivation |
---|---|---|
character | General term for letters, numbers, punctuation and other symbols. | Describes the symbol e.g., "lower case a" |
glyph | Visual structure | Visual representation of the symbol |
ligature | A single glyph that represents two or more characters | Used to improve how the characters look together, side-by-side (e.g., -> ) |
typeface | A collection of glyphs | Provide a consistent visual theme for the glyphs; a means to group related collections to represent "normal", "bold", "italic" etc... |
font | tool for selecting and positioning glyphs from a particular typeface | E.g., ensure a mono-space distribution, select the italic typeface from a given typeface |
To clarify the distinction between typeface and font, here is how one might use the terms in a sentence:
John designed a typeface that he intended to be used as a mono-spaced font. However, because the typeface is "sans-serif" (a category of typeface), it also looks good as a variable-width font.
Given the following process described at "freecodecamp",
Alacritty displays emojis (a type of glyph) encoded with a single code-point correctly. It fails with those that are encoded using two code-points.
Alacrity does not support ligatures. Ligatures are encoded using 2 code-points to render a single glyph. However, the challenge with ligatures is how to render 2 characters in a single glyph that consumes more than one "column" on the screen. It is different because the emojis that aren't displaying correctly use glyphs that are the same size as those that display correctly.
Ligatures and problematic emojis
Unless the lack of ligature support has to do with having to read-in 2 code-points for a single glyph, the issue here is unrelated to ligatures. When I was learning about ligatures a few years ago, it seems to me the challenge has more to do with the irregular size and thus presents a unique rendering challenge. Furthermore, unlike the ligature feature request, my issue is macOS specific.
Ligature support is a rendering issue. The emoji issue is the inability to map 2 code-points to a single glyph.
Grapheme clusters are not supported, see ligature issue.
@chrisduerr -- Thank you for the reply - clearly helpful. Just to confirm, does this mean it is not a macOS-specific issue?
Grapheme clusters are not supported on any platform. The only emoji-related issue that is specific to macOS is that font fallback is less reliable and thus sometimes the incorrect fonts can be loaded.
@chrisduerr Got it. So any glyph that is encoded with 2 code-points (a grapheme), isn't supported. Thank you.
For ligatures, if we solved the grapheme part of the problem, would we be able to render the > 1 column glyph?... or does that present another, incremental challenge?
As long as it's just a single grapheme, it will work just fine. It's just grapheme clusters that do not work.
For bug reports, the following information can help speed up the process. Please describe the bug that you have found and what you would expect to happen instead.
System
OS: macOS 12.1 on M1 Alacritty Version 0.10.0 (1)
Logs
I can only report the output from
infocmp alacritty
:A picture of the issue
my alacritty font configuration
config font does not seem to be a solution
I have tried to set this config file in several different ways to no avail. The need for this configuration seems off though because iTerm2 displays the emoji's as expected using the same
Hasklug Nerd Font
.This is a macos issue. I suspect the config font solutions are fixes for linux and other systems.
If anyone has avoided this issue on macos, please share!
Thank you!