bug#6718: 23.2; Should align glyphs according to grid in ansi-term

bug#6718: 23.2; Should align glyphs according to grid in ansi-term

[Jonathan Kleinehellefort]

I came across this when I tried using the font Inconsolata inside
ansi-term.  Inconsolata does not cover a couple of special Unicode
characters, some of which frequently show up in the output of various
terminal applications.

Emacs will then fall back on some other font with completely different
geometry for those, destroying the grid layout of the buffer.

Steps to reproduce:

 1. run "emacs -Q"
 2. M-x term
 4. type "pstree" into the shell
 5. Choose "Inconsolata" as your font

Result:

Characters now have non-uniform width and height. Note that the pretty
tree drawing gets destroyed.

Expected result:

Glyphs should be aligned in a grid.

Using a more comprehensive font (e.g. DejaVu Sans Mono) does not solve
this completely, as you can still get the same problem with e.g. Chinese
characters.



In GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-05-16 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Term

bug#6718: 23.2; Should align glyphs according to grid in ansi-term

[Stefan Kangas]

Jonathan Kleinehellefort <jk@molb.org> writes:

> I came across this when I tried using the font Inconsolata inside
> ansi-term.  Inconsolata does not cover a couple of special Unicode
> characters, some of which frequently show up in the output of various
> terminal applications.
>
> Emacs will then fall back on some other font with completely different
> geometry for those, destroying the grid layout of the buffer.
>
> Steps to reproduce:
>
>  1. run "emacs -Q"
>  2. M-x term
>  4. type "pstree" into the shell
>  5. Choose "Inconsolata" as your font
>
> Result:
>
> Characters now have non-uniform width and height. Note that the pretty
> tree drawing gets destroyed.
>
> Expected result:
>
> Glyphs should be aligned in a grid.
>
> Using a more comprehensive font (e.g. DejaVu Sans Mono) does not solve
> this completely, as you can still get the same problem with e.g. Chinese
> characters.

Is there really anything that can be done about this, besides a complete
redesign of how fonts work in Emacs?

bug#6718: 23.2; Should align glyphs according to grid in ansi-term

[Basil L. Contovounesios]

Stefan Kangas <stefan@marxist.se> writes:

> Jonathan Kleinehellefort <jk@molb.org> writes:
>
>> I came across this when I tried using the font Inconsolata inside
>> ansi-term.  Inconsolata does not cover a couple of special Unicode
>> characters, some of which frequently show up in the output of various
>> terminal applications.
>>
>> Emacs will then fall back on some other font with completely different
>> geometry for those, destroying the grid layout of the buffer.
>>
>> Steps to reproduce:
>>
>>  1. run "emacs -Q"
>>  2. M-x term
>>  4. type "pstree" into the shell
>>  5. Choose "Inconsolata" as your font
>>
>> Result:
>>
>> Characters now have non-uniform width and height. Note that the pretty
>> tree drawing gets destroyed.
>>
>> Expected result:
>>
>> Glyphs should be aligned in a grid.
>>
>> Using a more comprehensive font (e.g. DejaVu Sans Mono) does not solve
>> this completely, as you can still get the same problem with e.g. Chinese
>> characters.
>
> Is there really anything that can be done about this, besides a complete
> redesign of how fonts work in Emacs?

Is there any overlap here with https://debbugs.gnu.org/44664?

-- 
Basil

bug#6718: 23.2; Should align glyphs according to grid in ansi-term

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Thu, 19 Nov 2020 08:48:13 +0000
> Cc: Jonathan Kleinehellefort <jk@molb.org>, 6718@debbugs.gnu.org
> 
> >> Expected result:
> >>
> >> Glyphs should be aligned in a grid.
> >>
> >> Using a more comprehensive font (e.g. DejaVu Sans Mono) does not solve
> >> this completely, as you can still get the same problem with e.g. Chinese
> >> characters.
> >
> > Is there really anything that can be done about this, besides a complete
> > redesign of how fonts work in Emacs?
> 
> Is there any overlap here with https://debbugs.gnu.org/44664?

Yes, it's the same issue.

I think a good way forward is for someone to investigate which fonts
are typically used in xterm for CJK and other "unusual" scripts,
including characters reported in bug#44664, then we could perhaps see
how to improve the situation in Emacs in this respect.  I don't see
any easy ways to "fix" this except by clever font configuration, and
I'd be interested to know whether xterm does anything beyond using
fonts that are known to DTRT.

bug#6718: 23.2; Should align glyphs according to grid in ansi-term

[Stefan Kangas]

forcemerge 6718 44664
thanks

Eli Zaretskii <eliz@gnu.org> writes:

>> Is there any overlap here with https://debbugs.gnu.org/44664?
>
> Yes, it's the same issue.

OK; merging.