Re: displaying missing glyphs

[Yuri Khan]

On Tue, 13 Apr 2021 at 00:24, Leo Butler <leo.butler@umanitoba.ca> wrote:

> Thanks for the suggestion. I have attached a marked-up screen shot of an
> xterm (left) and gnome-terminal running `emacsclient -nw` and showing
> the same buffer. You can see there is a noticeable clipping of some of
> the characters in the xterm.
>
> According to lsof, gnome-terminal is using
>
>  /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf

The DejaVu Sans Mono font does not even contain glyphs for
MATHEMATICAL BOLD CAPITAL [A-Z] (on my Ubuntu 20.04, checked via
gucharmap(1)). The glyphs are taken from some other font that does
have them, possibly FreeSerif (which is not a monospace font, and even
if it were, it would not have the same metrics as DejaVu Sans Mono).

The difference in rendering stems from the way the two terminals paint
each cell. You will observe it more evidently if you enclose each
glyph in some delimiters, e.g. (insert (format "\n%s\n%x\t[%c]" x y
y)). Xterm seems to paint the next cell (space) opaquely, partially
erasing the MATHEMATICAL BOLD CAPITAL A. GNOME Terminal paints it
transparently so the rightmost part of the letter is still visible
under the closing bracket. Another terminal emulator, Kitty,
dynamically reduces the font size for the MATHEMATICAL BOLD CAPITAL A
so its width does not exceed the cell width.

Emacs running as a text-only application in a terminal emulator does
not, cannot, and should not know the font(s) it’s being rendered with
or any terminal-emulator-specific rendering peculiarities, or do
anything to improve the way it’s rendered.

Font fallback is hard, especially when you want character cells to
align perfectly (which, in case of a terminal emulator, you always
do). You might try filing a bug against Xterm.