help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: displaying missing glyphs


From: Leo Butler
Subject: Re: displaying missing glyphs
Date: Tue, 13 Apr 2021 12:00:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Yuri Khan <yuri.v.khan@gmail.com> writes:

> 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)). 

Yuri, thanks for that suggestion. After doing so, I can see that
gnome-terminal is scaling each glyph to fit in a fixed-size box, while
xterm is allowing it to overflow.

> 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.

Hmm, my gnome-terminal largely behaves the way that you say Kitty does...

>
> 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.

Yes, the thread started by my asking how I could fix the problem with
elisp. I was thinking of possibly using an overlay or something like
that.

>
> 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.

I will file a bug against the debian xterm package.

Leo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]