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.
Character A0
is an unbreakable space. It looks like it is between "Jakieś" and "informacje". Use your editor to replace it by a normal space and you should be good to go.
Advice: I've set up my editors (emacs, vim) to highlight unbreakable spaces because I sometimes unintentionally type some with AltGr+space when I hit space after typing a character requiring to press AltGr.
The warnings after your first guess seem to show that some chars (ę, ś, ż...) are encoded with combining diacritics rather than natively. E.g. ę == e (hex 65) + combining ogonek (hex 328) rather than "e with ogonek" (hex 119). How do you edit your source file? You may use a Compose key to produce "standalone" letters-with-diacritics, e.g. Compose e , for "ę".
Best Answer
If you want to use the
FAM
string to specify a font family you will need to use conventional names with the suffixesR B I BI
for roman, bold, italic, and bold-italic. In the linked-to example, the font family wasDejaVuSans
, so you need to provide fontsDejaVuSansR
,DejaVuSansB
,DejaVuSansI
, andDejaVuSansBI
. The following worked for me: