From: Leo Butler <leo.butler@umanitoba.ca>
To: Yuri Khan <yuri.v.khan@gmail.com>
Cc: Emacs <help-gnu-emacs@gnu.org>
Subject: Re: displaying missing glyphs
Date: Tue, 13 Apr 2021 12:00:57 -0500 [thread overview]
Message-ID: <86lf9myv92.fsf@x201.butler.org> (raw)
In-Reply-To: <CAP_d_8U7ga-dZ_7K=PMNxJQuaMa4JM7F6iW59LbGODD9MK2dnQ@mail.gmail.com> (Yuri Khan's message of "Tue, 13 Apr 2021 01:32:34 +0700")
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
prev parent reply other threads:[~2021-04-13 17:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 16:32 displaying missing glyphs Leo Butler
2021-04-09 17:50 ` Eli Zaretskii
2021-04-10 12:32 ` Andreas Eder
2021-04-10 12:47 ` Andreas Eder
2021-04-12 17:08 ` Leo Butler
2021-04-12 17:49 ` 2QdxY4RzWzUUiLuE
2021-04-12 18:45 ` Leo Butler
2021-04-12 19:19 ` 2QdxY4RzWzUUiLuE
2021-04-13 17:23 ` Leo Butler
2021-04-12 18:32 ` Yuri Khan
2021-04-13 17:00 ` Leo Butler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86lf9myv92.fsf@x201.butler.org \
--to=leo.butler@umanitoba.ca \
--cc=help-gnu-emacs@gnu.org \
--cc=yuri.v.khan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).