3

I've been trying for the past couple of days to get xterm to display the same font that I have gotten used to in konsole for the last few years – it works for me quite well even with relatively small face size. xterm seems to render the font in a way that's much more difficult for me to read.

Here's a couple of screenshots for comparison.

xterm:
xterm rendering

konsole:
konsole rendering

The font in question is DejaVu Sans Mono 8. Both are antialiased, obviously. I even applied the color scheme from konsole to xterm, thinking that might be the reason for the difference, but it was not. Also, in konsole I have the “Draw intense colors in bold font” checkbox enabled, but the difference is clear in both the bold and regular font.

The difference appears to be in how aggressively each application antialiases the font. In xterm the text is much more blurry and also considerably more difficult to read, at least to me. It is probably most obvious with the character m, which in the non-bold version has the first “leg” spread across two pixels in xterm, whereas in konsole, it is nice and sharp.

I am getting the same results on both Gentoo and Ubuntu, and with both the conservative setup in /etc/fonts/conf.d on my Gentoo laptop, as well as the all-in setup on Ubuntu.

Bonus points if you can figure out why the hell does xterm fail to display some of the non-Latin characters, although I don't mind that as much. It just doesn't make any sense to me. It might be a clue, though...

Here's the relevant part of my .Xresources:

XTerm*faceName: DejaVu Sans Mono
XTerm*faceSize: 8
XTerm*background: #000000
XTerm*foreground: #B2B2B2
XTerm*color0:  #000000
XTerm*color1:  #B21818
XTerm*color2:  #18B218
XTerm*color3:  #B26818
XTerm*color4:  #1818B2
XTerm*color5:  #B218B2
XTerm*color6:  #18B2B2
XTerm*color7:  #B2B2B2
XTerm*color8:  #686868
XTerm*color9:  #FF5454
XTerm*color10: #54FF54
XTerm*color11: #FFFF54
XTerm*color12: #5454FF
XTerm*color13: #FF54FF
XTerm*color14: #54FFFF
XTerm*color15: #FFFFFF
XTerm*boldColors: true

Update: To clarify, getting xterm to use TTF is trivial; what I'm looking for is a way to fine-tune the way TTF are rendered in xterm to match the settings used by konsole (and pretty much any other X11 app, for that matter). For some reason, xterm seems to ignore everything besides the face name and face size of the TTF font I try to set, either in Xresources, or in my fontconfig settings (which are correctly picked up by the rest of the system).

1

In xterm(1) you can change the font type by holding down the CTRL key and right-clicking in the window. I say sort of because you don't get a lot of choices. Clicking the "TrueType" option will give you results closer to what you are looking for. You can gain more control by editing the Xresources file as I am sure you know - See: https://wiki.archlinux.org/index.php/Xterm for examples on how to modify this to suit your needs.

xterm(1) does not display most non Latin characters by default. you can use the -u8 option or use the uxterm(1) wrapper

Try this command, you can adjust the size to suite your need or leave it out and CTRL-rightclick to change the font size

xterm -u8 -fn 7x13 -fa "DejaVu Sans Mono:size=8:antialias=true"

  • As you can see in the screenshot, xterm already does use TTF, and Unicode is enabled as well – the screenshot shows a bunch of Unicode characters that, as far as I know, don't fit into a single 8-bit encoding (Cyrillic, Greek, Central-European accents and a bunch of scripts I have no idea what they are). It only fails to display a few particular scripts. Also, the ctrl+RMB menu only makes available a few additional font configurations that can be set by the resources font1 through font6. – koniiiik Jan 21 '15 at 9:23
0

This is due to GTK apps and xterm using wildly different ways to configure fonts. GTK uses font-config, while xterm/Xft use X resources.

To configure Xft fonts using X resources add this to your ~/.Xresources:

  Xft.rgba: rgb

This setting modifies the kind of antialiasing. Here are examples xterm screenshots taken with xmag, without any rgba setting, and rgb, grb, vrgb. They all have different crispness, color fidelity and apparent brightness.

enter image description here enter image description here enter image description here enter image description here

There are also knobs for Xft.antialias, Xft.hinting, Xft.hintstyle, Xft.lcdfilter and others. For details see some fontconfig documentation.

  • Thanks, but... For one thing, I believe that xterm does in fact use fontconfig, because I get some messages from fontconfig on stderr when starting xterm. As for using Xft resources instead, xterm stubbornly ignores all Xft resources, as well as any additional options passed inside the faceName resource. (In faceName it only recognizes size.) – koniiiik Mar 9 '15 at 17:01
  • @koniiiik This could be due to different ./configure options being used. I always compile xterm from source (my screenshots are from xterm-314). There are a few freetype-related configure options you can play around with. I used the defaults for those (i.e. did not use --disable-freetype). I'm on FreeBSD 10 and 11. – Jens Mar 9 '15 at 17:55
0

The difference in rendering you're seeing between Konsole and xterm comes down to the fontconfig hinting settings. You can tell that hinting is involved if you compare the shapes of the glyphs between the two screenshots; the zero is shaped slightly differently in Konsole because it has been snapped to the pixel grid (which is among the things font hinting does).

Konsole is likely picking up settings from some additional layer of KDE configuration, while xterm only honors the low-level fontconfig settings.

I've been working on this on my Arch system recently, and the combination of settings that most closely replicate what you're seeing in Konsole are (put this in your .Xresources):

Xft.antialias: 1
Xft.autohint: 1
Xft.hintstyle: hintslight

Some fonts include hint information from the designers of the font. Some don't. The freetype autohinter (Xft.autohint: 1) will generate hints for the font, and the hint level hintslight will fall back to the included hints if present. It's probably also worth trying hintfull; comes down to your preference, plus the quality of hints present in the font you're using.

(You aren't using subpixel antialiasing in those screenshots, and another commenter already explained how to start using it if you want.)

Here are my before and after screenshots at each hint level. (7pt Anonymous Pro on a 192dpi display.)

Defaults:

ASCII character set with default hinting

Config above:

ASCII character set with slight hinting

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.