Add this to yours ~/.config/fontconfig/fonts.conf
file to set Font B as default monospace font
<match target="pattern">
<test name="family" qual="any">
<string>monospace</string>
</test>
<edit binding="strong" mode="prepend" name="family">
<string>Font B</string>
</edit>
</match>
Or to /etc/fonts/local.conf
to set it system-wide.
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
The solution is to install appropriate font package to the system which is
ttf-devanagari-fonts
here. (You can search on repository).Package Description:
So,
sudo apt-get install ttf-devanagari-fonts
installs the devanagari fonts:Now, Devanagari fonts are displaying correctly.
Update: For the latest current (LTS) version of Trisquel GNU Linux i.e 8.0 Flidas, install the following package:
And then set Lohit Devanagari by creating following configuration file as described here:
Logout and re-login to get the effect.