GNU bug report logs - #44664
28.0.50; troubles with some chars in term

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Sun, 15 Nov 2020 19:46:01 UTC

Severity: minor

Tags: confirmed

Merged with 6718, 36983

Found in versions 23.2, 25.3, 27.0.50, 28.0.50

Full log


Message #138 received at 44664 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
Subject: Re: bug#44664: 28.0.50; troubles with some chars in term
Date: Wed, 25 Nov 2020 17:35:39 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org,  bugs <at> gnu.support,  44664 <at> debbugs.gnu.org
> Date: Wed, 25 Nov 2020 07:55:13 +0100
> 
> But I was just experimenting a bit, and I wondered how you can force
> Emacs into using a specific font for some text.  The following does not
> work:
> 
> (insert (propertize "fooѾx" 'face '(:family "Futura")))
> 
> Now, that font doesn't have the Ѿ glyph, so I'd expect Emacs to tofu
> that character, but instead it renders it using DejaVu Sans?

This is a subtlety of the Emacs handling of faces: the font part of
the face spec only specifies the font for ASCII characters.  When
Emacs needs to display non-ASCII characters, it internally creates a
new face, which is based on the ASCII face, but uses a different font
if necessary.  Those internally-created faces aren't visible from
Lisp, but you can see them in the frame's face cache and in the glyph
matrices.

> But as you can see, this isn't really monospaced, either -- the tofu
> glyphs here are narrower than the other glyphs.  And...  hang on --
> there's still some glitches, but they are much smaller than before.
> 
> I've tried a couple more monospaced fonts, but none seem to have full
> coverage.
> 
> I'm starting to wonder whether gnome-terminal is just faking the
> monospaceness?  That is -- if the glyph is too wide, it's just narrowing
> it?

Maybe.  We can do that as well, btw.  We already do something like
that with fonts that declare too large height for its character
glyphs: we override that with a reasonable value.  We could do
something similar for the width, conditioned on some buffer-local
variable.  The relative complexity of this wrt what terminal emulators
do is that terminal emulators can do that always, whereas Emacs cannot
do that by default, it must be an opt-in feature requested by the
likes of term.el.




This bug report was last modified 3 years and 131 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.