Writing in 2016, talking about xterm patch #278 (released in 2012):
xterm uses a single font, rather than font sets which are supported by several other terminals. The pseudo-graphic characters in this (pasted from xterm):
⎛ ⎽⎽⎽⎽⎽⎽⎽ ⎞
⎜ ╱ 3 ⎟
⎜ ╱ x ⎟
⎜ ╱ ───── , 1⎟
⎝╲╱ x + 1 ⎠
are not provided by the TypeType font specified here:
xterm.vt100.faceName: Terminus
xterm.vt100.faceSize: 14
Other terminals, given that font would provide those characters from another font.
The way to make xterm work is
- specify a font which does cover all of the characters needed, and
- tell it to use UTF-8 encoding.
The latter is addressed for most users by the default setting of the locale resource: xterm will (usually) use UTF-8 encoding. But the default behavior is VT100-compatible, hence the use of ISO-8859-1 compatible fonts.
- Terminus uses more glyphs than that, but falls far short of covering all pseudo-graphics in Unicode.
- The ones that display as
n are U+239B, U+239C, U+239D, U+239E, U+23A0.
- The version of Terminus in Debian 7 (and Debian testing) has less than 256 glyphs and happens to show
n as described in the question.
That happens because (although xterm knows that the glyphs are missing), it has printed the string using the font, assuming that (like most other fonts) missing entries will be shown as blanks. In this case, the freetype library seems to be mapping the low-order byte of the Unicode values into the range that Terminus supports. That happens to fall in a range that the font displays as n (for "no such character"):
The quick workaround uses the uxterm script, which selects a different font and ensures that UTF-8 encoding is used.
Further reading:
Terminus Font is a clean, fixed width bitmap font, designed for long (8 and more hours per day) work with computers. Version 4.40 contains 1241 characters, covers about 120 language sets and supports ISO8859-1/2/5/7/9/13/15/16, Paratype-PT154/PT254, KOI8-R/U/E/F, Esperanto, many IBM, Windows and Macintosh code pages, as well as the IBM VGA, vt100 and xterm pseudographic characters.
The above was talking about xterm patch #278 which was four years old in 2016. Development of xterm is ongoing, and beginning with patch #338 (late 2018) there is support for TrueType fontsets. Here is a screenshot using the OP's resource-settings from xterm patch #342 (#343 will probably be out "soon"):
Using the -report-fonts option, I see that it loaded these font-files (treating bold/italic as the "same" as normal, and using a second font for the special characters):
file=/usr/share/fonts/X11/misc/ter-u18n\_iso-8859-1.pcf.gz
file=/usr/share/fonts/X11/misc/ter-u18b\_iso-8859-1.pcf.gz
file=/usr/share/fonts/X11/misc/ter-u18n\_iso-8859-1.pcf.gz
file=/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
The actual number of fonts depends on what you want to do. In testing the existing range of Unicode values, it may use a couple of dozen fonts.
Best Answer
Actually,
xterm(andxfd) can use TrueType fonts, using the-faoption. With the latter, you can see that0xee20is missing from the font:Given that, xterm would show a missing glyph (because it uses only one font). Likely vte is doing the same because none of the fallback fonts which it may be using has this particular private use code.
For comparison, here is a screenshot with
xfddisplaying the PCF font (which does have the glyph):Whether the fonts are "identical" depends on how they were created (and maintained). I see 7 missing glyphs on the screenshot of the TrueType font, and none on the PCF font.