unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Yuri Khan <yuri.v.khan@gmail.com>
To: Leo Butler <leo.butler@umanitoba.ca>
Cc: Emacs <help-gnu-emacs@gnu.org>, Andreas Eder <a_eder_muc@web.de>
Subject: Re: displaying missing glyphs
Date: Tue, 13 Apr 2021 01:32:34 +0700	[thread overview]
Message-ID: <CAP_d_8U7ga-dZ_7K=PMNxJQuaMa4JM7F6iW59LbGODD9MK2dnQ@mail.gmail.com> (raw)
In-Reply-To: <86y2dn1ldz.fsf@x201.butler.org>

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.



  parent reply	other threads:[~2021-04-12 18:32 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 [this message]
2021-04-13 17:00       ` Leo Butler

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='CAP_d_8U7ga-dZ_7K=PMNxJQuaMa4JM7F6iW59LbGODD9MK2dnQ@mail.gmail.com' \
    --to=yuri.v.khan@gmail.com \
    --cc=a_eder_muc@web.de \
    --cc=help-gnu-emacs@gnu.org \
    --cc=leo.butler@umanitoba.ca \
    /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).