8

I don't have a general problem with XTerm and Unicode. For the most part, things are working. This works great:

$ echo "¿dónde está la llama?"
¿dónde está la llama?

As does this:

$ echo -e "\xE2\x98\xA0"
☠

But this fails:

$ echo -e "\xE2\xA4\xB7"

Rather than the expected output (⤷, aka ARROW POINTING DOWNWARDS THEN CURVING RIGHTWARDS) I get the dreaded box. I'm currently using:

xterm*faceName: Hack Regular:size=12:antialias=true

This is the same font I use with gnome-terminal, which displays the same character correctly. I've also tried the same thing with a variety of other monospace fonts (Droid Sans Mono, DejaVu Sans Mono, Liberation Mono), which all have the same behavior in XTerm (but work fine elsewhere). In fact, looking at the characters between \u2620, which displays correctly, and \u2937, which does not, there are a number of characters that don't seem to display correctly in XTerm:

$ python
>>> for x in range(0x2620, 0x2938):
...    print(unichr(x))

I'd like to understand what's going on here. Why does XTerm have trouble displaying some of these characters, but not others?

Gilles 'SO- stop being evil'
  • 829,060
larsks
  • 34,737

1 Answers1

7

short: xterm uses a single font (except for the special cases of double-width characters), while the other terminals use additional fonts (and they use those fonts for the characters not found in your requested font).

long: the character you are interested in is not part of the font, which appears to be something like fonts-hack-tty in Debian. The missing code is 0x2937, which you can see using xfd -fa hack is not supplied by the font (hint: the first on the page is 0x2987):

enter image description here

The short description of the font gives its intended use:

No frills. No gimmicks. Hack is hand groomed and optically balanced to be a workhorse face for code.

which (since "code" generally is the POSIX character set, plus whatever people think makes good comments) is likely to be small. This example has more non-POSIX characters than the usual. Starting with the ASCII+Latin1:

enter image description here

there are a few hundred glyphs in the font (another dozen screenshots would be needed to show these, though more than half show a small number of glyphs). The second page for instance is partly supported:

enter image description here

Prompted by a comment, I traced gnome-terminal to see that it loads these font files:

/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraSeBd.ttf
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf

and that 0x2937 is supplied by the last one. The actual details may differ on your configuration.

Thomas Dickey
  • 76,765
  • Missing glyphs was my first theory, which is why I tried a variety of other fonts. Apparently they're all somewhat light in the same. TIL about xfd, so that was useful. Do you know from which font something like gnome-terminal is getting the missing glyphs? There doesn't appear to be an explicit configuration for that, at least in gnome-terminal. Maybe it's a global Gnome setting somewhere... – larsks May 03 '16 at 23:20
  • Not offhand - you might see it using strace. – Thomas Dickey May 03 '16 at 23:21
  • I had been using Gnome charmap to view the glyphs in Hack, and it shows a lot of extra glyphs that xfd doesn't. This answer helped me work out the source of my problem. Now I wonder why charmap is showing symbols which aren't in the selected font? I thought that showing characters from a given font was the whole point of the program! – Aaron F Sep 03 '18 at 08:16