GNU bug report logs -
#26742
Display bug with composed strings
Previous Next
Full log
View this message in rfc822 format
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Clément Pit--Claudel <clement.pitclaudel <at> live.com>,
> 26742 <at> debbugs.gnu.org
> Date: Tue, 02 May 2017 19:18:22 +0200
>
> I see the same effect, if I use Droid Sans Mono as the default font, but
> not with DejaVu Sans Mono (in the latter case both characters are
> selected from this font).
>
> The component character(s) are displayed by these fonts (glyph codes):
> ℝ: xft:-unknown-Linux Libertine O-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1 (#x748)
> ≤: xft:-unknown-Droid Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 (#x231)
Aha, so this is somehow font-depended after all. Thanks.
For the record, on my system, the problem doesn't happen even if the
two characters are displayed using different fonts:
The component character(s) are displayed by these fonts (glyph codes):
ℝ: uniscribe:-outline-Symbola-normal-normal-normal-serif-13-*-*-*-p-*-iso10646-1 (#x471)
≤: uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x94)
Does anything change if you add
--eval "(setq use-default-font-for-symbols nil)"
to the Emacs command line, before the file name to visit? In my case,
this still doesn't reproduce the problem, and the two characters still
use 2 different fonts, although ≤ now uses a different font, not the
one used by the default face.
This bug report was last modified 8 years and 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.