GNU bug report logs - #76967
30.1; Specific UTF-8 characters causes misalignments on PGTK

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76967 in the body.
You can then email your comments to 76967 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: artur <amad <at> atl.tools>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; Specific UTF-8 characters causes misalignments on PGTK
Date: Tue, 11 Mar 2025 20:07:11 +0000

To reproduce this bug, you must:
1. Open a terminal (such as emacs-eat, vterm, the usual emacs terminal)
2. Open btop (I used `nix run "nixpkgs#btop"` but you could use `pacman
-S btop | yes && btop` on Arch Linux)

The effects caused are severe distortion to where the program isn't
really usable. You may see extreme graphical issues such as:
- More violent refreshes
- Characters not lining up either barely or Finnishly gapped

A recipe will not be provided, as the terminals provided by Emacs cannot
render btop period.


In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.48,
cairo version 1.18.2)
System Description: NixOS 25.05 (Warbler)

Configured using:
'configure
--prefix=/nix/store/q9plzwv5nr7b0napm8wqw7n8diqkzbk9-emacs-pgtk-30.1
--disable-build-details --with-modules --with-pgtk
--with-compress-install --with-toolkit-scroll-bars
--with-native-compilation --without-imagemagick --with-mailutils
--without-small-ja-dic --with-tree-sitter --without-xinput2
--without-xwidgets --with-dbus --with-selinux'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
 value of $EMACSLOADPATH:
 value of $EMACSNATIVELOADPATH:
 value of $LANG: de_DE.UTF-8
 locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
 mood-line-mode: t
 helm-mode: t
 helm-minibuffer-history-mode: t
 savehist-mode: t
 which-key-mode: t
 envrc-global-mode: t
 spacious-padding-mode: t
 override-global-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 show-paren-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 blink-cursor-mode: t
 minibuffer-regexp-mode: t
 buffer-read-only: t
 line-number-mode: t
 indent-tabs-mode: t
 transient-mark-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t

Load-path shadows:
/nix/store/36pj459qgxdr31ck8p34knf62krvp5rn-emacs-packages-deps/share/emacs/site-lisp/site-start 
hides 
/nix/store/q9plzwv5nr7b0napm8wqw7n8diqkzbk9-emacs-pgtk-30.1/share/emacs/site-lisp/site-start
/nix/store/36pj459qgxdr31ck8p34knf62krvp5rn-emacs-packages-deps/share/emacs/site-lisp/elpa/transient-20250306.1916/transient 
hides 
/nix/store/q9plzwv5nr7b0napm8wqw7n8diqkzbk9-emacs-pgtk-30.1/share/emacs/30.1/lisp/transient
/nix/store/36pj459qgxdr31ck8p34knf62krvp5rn-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq 
hides 
/nix/store/q9plzwv5nr7b0napm8wqw7n8diqkzbk9-emacs-pgtk-30.1/share/emacs/30.1/lisp/emacs-lisp/seq
/nix/store/36pj459qgxdr31ck8p34knf62krvp5rn-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat 
hides 
/nix/store/q9plzwv5nr7b0napm8wqw7n8diqkzbk9-emacs-pgtk-30.1/share/emacs/30.1/lisp/emacs-lisp/compat

Features:
(shadow sort mail-extr emacsbug message yank-media puny rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr
cl-extra winner cursor-sensor tramp-archive tramp-gvfs dbus xml
helm-command helm-elisp helm-eval edebug helm-info comp-run comp-common
display-line-numbers eglot external-completion jsonrpc xref flymake
thingatpt seq-25 diff ert pp ewoc debug backtrace find-func warnings
compile text-property-search imenu mood-line helm-mode helm-misc
helm-files image-dired image-dired-tags image-dired-external
image-dired-util image-mode dired dired-loaddefs exif filenotify tramp
trampver tramp-integration files-x tramp-message help-mode tramp-compat
xdg shell pcomplete parse-time iso8601 time-date tramp-loaddefs
helm-buffers helm-x-icons helm-occur helm-tags helm-locate helm-grep
helm-regexp format-spec helm-utils helm-help helm-types helm
helm-global-bindings helm-easymenu edmacro kmacro helm-core helm-source
helm-multi-match helm-lib async savehist which-key envrc inheritenv
diff-mode track-changes config spacious-padding cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
python rx project compat pcase treesit comint ansi-osc ring ansi-color
base16-everforest-dark-hard-theme base16-theme bind-key easy-mmode
base16-theme-autoloads envrc-autoloads haskell-mode-autoloads
helm-autoloads helm-core-autoloads async-autoloads inheritenv-autoloads
mood-line-autoloads nix-mode-autoloads magit-section-autoloads
llama-autoloads qml-mode-autoloads rust-mode-autoloads
spacious-padding-autoloads info transient-autoloads vterm-autoloads
wfnames-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt
gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
touch-screen pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk multi-tty move-toolbar
make-network-process native-compile emacs)

Memory information:
((conses 16 321284 30614) (symbols 48 22076 0) (strings 32 70691 3306)
(string-bytes 1 2695713) (vectors 16 38770)
(vector-slots 8 464270 12189) (floats 8 153 1264)
(intervals 56 1019 110) (buffers 992 16))


------------
Artur Manuel
amadaluzia

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

From: Po Lu <luangruo <at> yahoo.com>
To: artur <amad <at> atl.tools>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Wed, 12 Mar 2025 11:37:23 +0800

artur <amad <at> atl.tools> writes:

> To reproduce this bug, you must:
> 1. Open a terminal (such as emacs-eat, vterm, the usual emacs terminal)
> 2. Open btop (I used `nix run "nixpkgs#btop"` but you could use `pacman
> -S btop | yes && btop` on Arch Linux)
>
> The effects caused are severe distortion to where the program isn't
> really usable. You may see extreme graphical issues such as:
> - More violent refreshes
> - Characters not lining up either barely or Finnishly gapped
>
> A recipe will not be provided, as the terminals provided by Emacs cannot
> render btop period.

In that case, would you be so kind as to provide a screenshot or the
like?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 76967 <at> debbugs.gnu.org, amad <at> atl.tools
Subject: Re: bug#76967: 30.1;
 Specific UTF-8 characters causes misalignments on PGTK
Date: Wed, 12 Mar 2025 15:59:59 +0200

> Cc: 76967 <at> debbugs.gnu.org
> Date: Wed, 12 Mar 2025 11:37:23 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> artur <amad <at> atl.tools> writes:
> 
> > To reproduce this bug, you must:
> > 1. Open a terminal (such as emacs-eat, vterm, the usual emacs terminal)
> > 2. Open btop (I used `nix run "nixpkgs#btop"` but you could use `pacman
> > -S btop | yes && btop` on Arch Linux)
> >
> > The effects caused are severe distortion to where the program isn't
> > really usable. You may see extreme graphical issues such as:
> > - More violent refreshes
> > - Characters not lining up either barely or Finnishly gapped
> >
> > A recipe will not be provided, as the terminals provided by Emacs cannot
> > render btop period.
> 
> In that case, would you be so kind as to provide a screenshot or the
> like?

Yes, it's hard to make progress with this report without so much as
knowing which characters cause the problem.  A screenshot or any other
information about that would go a long way towards helping us
understand what could be the problem.

TIA

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

From: artur <amad <at> atl.tools>
To: 76967 <at> debbugs.gnu.org
Subject: Fwd: Re: bug#76967: 30.1; Specific UTF-8 characters causes
 misalignments on PGTK
Date: Wed, 12 Mar 2025 15:23:01 +0000

[Message part 1 (text/plain, inline)]

> In that case, would you be so kind as to provide a screenshot or the
> like?

Okay, here are the needed screenshots.

The first screenshot was taken on `ansi-term`.

The second screenshot was taken on `vterm`.

The third screenshot was taken on `eat`.

The fourth screenshot was taken on `foot`.
------------
Artur Manuel
amadaluzia

[Screenshot from 2025-03-12 08-00-44.png (image/png, attachment)]

[Screenshot from 2025-03-12 08-00-22.png (image/png, attachment)]

[Screenshot from 2025-03-12 07-58-28.png (image/png, attachment)]

[Screenshot from 2025-03-12 07-59-51.png (image/png, attachment)]

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

From: artur <amad <at> atl.tools>
To: 76967 <at> debbugs.gnu.org
Subject: Re: Fwd: Re: bug#76967: 30.1; Specific UTF-8 characters causes
 misalignments on PGTK
Date: Wed, 12 Mar 2025 15:24:48 +0000

I had now realised I had failed to email the correct account. Apologies
------------
Artur Manuel
amadaluzia

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: artur <amad <at> atl.tools>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1;
 Specific UTF-8 characters causes misalignments on PGTK
Date: Thu, 13 Mar 2025 10:22:59 +0200

> Date: Wed, 12 Mar 2025 15:23:01 +0000
> From:  artur via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
>  > In that case, would you be so kind as to provide a screenshot or the
>  > like?
> 
> Okay, here are the needed screenshots.
> 
> The first screenshot was taken on `ansi-term`.
> 
> The second screenshot was taken on `vterm`.
> 
> The third screenshot was taken on `eat`.
> 
> The fourth screenshot was taken on `foot`.

Maybe I'm missing something, but the display seems to be made of plain
ASCII characters?  Would you mind telling which specific characters
cause misalignment in that case?

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

From: Artur Manuel <amad <at> atl.tools>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments on PGTK
Date: Thu, 13 Mar 2025 10:07:14 +0000

[Message part 1 (text/plain, inline)]

I think a cause of these misalignments might be the braille text but I made a test folder with 你好 as the name and a misalignment still happens. I am not on my computer right now but I can provide screenshots when I am.
Artur Manuel
amadaluzia

[Message part 2 (text/html, inline)]

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

From: Artur Manuel <amad <at> atl.tools>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments on PGTK
Date: Thu, 13 Mar 2025 10:36:25 +0000

I apologise if I am breaking mailing list
protocols by the way, I forgot about
the 72 characters a line guideline.

Artur Manuel
amadaluzia

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artur Manuel <amad <at> atl.tools>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1;
 Specific UTF-8 characters causes misalignments on PGTK
Date: Thu, 13 Mar 2025 16:20:02 +0200

> Date: Thu, 13 Mar 2025 10:07:14 +0000
> From: Artur Manuel <amad <at> atl.tools>
> CC: 76967 <at> debbugs.gnu.org
> 
> I think a cause of these misalignments might be the braille text but I made a test folder with 你好 as the name
> and a misalignment still happens. I am not on my computer right now but I can provide screenshots when I
> am.

I think it would help us greatly if you show some simple text with the
problematic characters that cannot be aligned, whereas replacing those
characters with ASCII characters solves the alignment issue.

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

From: artur <amad <at> atl.tools>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Thu, 13 Mar 2025 17:42:31 +0000

> I think it would help us greatly if you show some simple text with 
the
> problematic characters that cannot be aligned, whereas replacing 
those
> characters with ASCII characters solves the alignment issue.

It really varies on the font. For example, using Departure Mono causes
any non Latin/Numerical character to not work as intended. On fonts such
as Iosevka, Source Code Pro or DejaVu Sans Mono, pipeline characters
work as intended but starts misaligning when you are using Braille or
CJK. FreeMono works without a hitch.

------------
Artur Manuel
amadaluzia

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: artur via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76967 <at> debbugs.gnu.org, artur <amad <at> atl.tools>
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Thu, 13 Mar 2025 19:13:42 +0100

artur via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

>> I think it would help us greatly if you show some simple text with
>   the
>> problematic characters that cannot be aligned, whereas replacing
>   those
>> characters with ASCII characters solves the alignment issue.
>
> It really varies on the font. For example, using Departure Mono causes
> any non Latin/Numerical character to not work as intended. On fonts such
> as Iosevka, Source Code Pro or DejaVu Sans Mono, pipeline characters
> work as intended but starts misaligning when you are using Braille or
> CJK. FreeMono works without a hitch.

Maybe you should look at what font is used on Braille or CJK characters
with "C-u C-x =" when you see such misalignment.  With fontsets, Emacs
tries really hard to find a suitable glyph for a given character even
using a different font which, most probably, will have a different width
and cause misalignment.
-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: artur <amad <at> atl.tools>
Cc: 76967 <at> debbugs.gnu.org
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Thu, 13 Mar 2025 21:26:04 +0200

> Date: Thu, 13 Mar 2025 17:42:31 +0000
> From: artur <amad <at> atl.tools>
> Cc: 76967 <at> debbugs.gnu.org
> 
>  > I think it would help us greatly if you show some simple text with 
> the
>  > problematic characters that cannot be aligned, whereas replacing 
> those
>  > characters with ASCII characters solves the alignment issue.
> 
> It really varies on the font. For example, using Departure Mono causes
> any non Latin/Numerical character to not work as intended. On fonts such
> as Iosevka, Source Code Pro or DejaVu Sans Mono, pipeline characters
> work as intended but starts misaligning when you are using Braille or
> CJK. FreeMono works without a hitch.

When you say "using font so-and-so", do you mean the font used for the
default face?  If so, please check whether the problematic characters
are rendered using some different font.  E.g., I'd expect Braille or
CJK characters to use a different font.  "C-u C-x =" with point on the
character will tell you what font is used for displaying that
character.

If some characters are using a different font, then it is very likely
that you will have misalignment, because the glyphs of those other
fonts have different metrics from those of the default face's font.

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

From: artur <amad <at> atl.tools>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76967 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Thu, 13 Mar 2025 20:45:57 +0000

[Message part 1 (text/plain, inline)]

> When you say "using font so-and-so", do you mean the font used for 
the
> default face?

I meant for the default face, yes.

> Maybe you should look at what font is used on Braille or CJK 
characters
> with "C-u C-x =" when you see such misalignment. With fontsets, Emacs
> tries really hard to find a suitable glyph for a given character even
> using a different font which, most probably, will have a different 
width
> and cause misalignment.

> If so, please check whether the problematic characters are rendered
> using some different font. E.g., I'd expect Braille or CJK characters
> to use a different font.

And you are absolutely right to believe this - seems as if with 
Departure
Mono, separator blocks are being rendered with FreeSerif. Not really
surprised why it was breaking now. However, in foot it finds the correct
glyph in with the same font? Looks like Emacs was *very* eager to 
replace
the glyph even if a matching one existed...

I'll throw in some screenshots. If any more information is needed, just 
let
me know.
------------
Artur Manuel
amadaluzia

[Screenshot from 2025-03-13 20-42-14.png (image/png, attachment)]

[Screenshot from 2025-03-13 20-42-44.png (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: artur <amad <at> atl.tools>
Cc: 76967 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Fri, 14 Mar 2025 09:12:50 +0200

> Date: Thu, 13 Mar 2025 20:45:57 +0000
> From: artur <amad <at> atl.tools>
> Cc: 76967 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>
> 
>  > When you say "using font so-and-so", do you mean the font used for 
> the
>  > default face?
> 
> I meant for the default face, yes.
> 
>  > Maybe you should look at what font is used on Braille or CJK 
> characters
>  > with "C-u C-x =" when you see such misalignment. With fontsets, Emacs
>  > tries really hard to find a suitable glyph for a given character even
>  > using a different font which, most probably, will have a different 
> width
>  > and cause misalignment.
> 
>  > If so, please check whether the problematic characters are rendered
>  > using some different font. E.g., I'd expect Braille or CJK characters
>  > to use a different font.
> 
> And you are absolutely right to believe this - seems as if with 
> Departure
> Mono, separator blocks are being rendered with FreeSerif. Not really
> surprised why it was breaking now. However, in foot it finds the correct
> glyph in with the same font? Looks like Emacs was *very* eager to 
> replace
> the glyph even if a matching one existed...

I think Emacs ought to try to use the default font where it can do the
job.  Can you use some font-viewing utility to check if the default
face's font has glyphs for the problematic characters, when Emacs uses
a different font for them?  If Emacs ignores existing glyphs of the
default font and uses a different font, there could be a way of
dealing with these problems.  But in general, we can only ensure
alignment if glyphs from the same font are used for the characters.

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

From: Artur Manuel <amad <at> atl.tools>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76967 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Sat, 15 Mar 2025 11:21:03 +0000

> Can you use some font-viewing utility to check if the default
> face's font has glyphs for the problematic characters, when Emacs 
uses
> a different font for them?
Did that just now on the problematic characters. I can finally conclude
that this is a font-wise issue. I believe the solution is to just force
fixed-pitch on fonts (like what foot is doing) instead of allowing fonts
of varying width to do as they please.

However, I feel like if forced fixed-width were to be implemented in the
future, it would need to be done as a special mode which toggles it.
Since EWW (I think at least) and some Org-mode users would prefer to use
variable-pitch.
------------
Artur Manuel
amadaluzia

Message #55 received at 76967-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artur Manuel <amad <at> atl.tools>
Cc: 76967-done <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#76967: 30.1; Specific UTF-8 characters causes misalignments
 on PGTK
Date: Sat, 29 Mar 2025 14:18:20 +0300

> Date: Sat, 15 Mar 2025 11:21:03 +0000
> From: Artur Manuel <amad <at> atl.tools>
> Cc: 76967 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
> 
>  > Can you use some font-viewing utility to check if the default
>  > face's font has glyphs for the problematic characters, when Emacs 
> uses
>  > a different font for them?
> Did that just now on the problematic characters. I can finally conclude
> that this is a font-wise issue. I believe the solution is to just force
> fixed-pitch on fonts (like what foot is doing) instead of allowing fonts
> of varying width to do as they please.
> 
> However, I feel like if forced fixed-width were to be implemented in the
> future, it would need to be done as a special mode which toggles it.
> Since EWW (I think at least) and some Org-mode users would prefer to use
> variable-pitch.

No further comments within 2 weeks, so I'm closing this bug.

Previous Next

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