A semi-brief history and overview of X fonts and font rendering technology
Because I've just been mucking around in this swamp, I feel like writing all of this down.
In the very beginning, X had some simple bitmap fonts in the server
with equally simple names that were basically labels; ie, the X server
attached no particular meaning to the font names, which were created by
people mostly to be short and sometimes to be vaguely meaningful. Some
of these font names linger on in X today; the most well known one is
fixed, the name for the default monospace font (and font size), but
there are others like
6x13bold. The X clients just asked
the server to display some text in the named font, and the server
handled all of the rendering and drawing.
(Today these font names are implemented as aliases for other fonts.)
As the X server evolved, it grew more bitmap fonts. Fonts from different vendors, fonts in more sizes, proportional fonts as well as monospaced ones, fonts for different resolutions (75dpi versus 100dpi), fonts for different character set encodings, and so on. It was clear that ad-hoc font names weren't going to scale because no one was going to be able to keep fonts straight or find one. So the X people invented a naming convention for their fonts, the X logical font description (XLFD). In theory an XLFD name describes most of the important attributes of a font, things like the point and pixel size, the slant, the style, whether it's proportional or monospaced, and so on. Along with XLFD names and their defined structure, the X people introduced the idea of wildcard matches so that X programs could say 'I don't really care which vendor it comes from, I just want whatever 15 pixel monospaced font you have'.
(For backwards compatibility, the original simple X font names were defined to be acceptable XLFD font names (although you can't use wildcards with them).)
Initially XLFD fonts were still all bitmapped fonts, just better named and more numerous than before. However the X server soon got additional font rendering support that let it handle several scalable font formats of the time. Scalability was implemented in XLFD font names in a straightforward way; if the font name itself had zeros in various resolution related fields, you knew that the X server could and would render it at whatever pixel size you asked for.
At some point, people observed that the precious X server was spending a
bunch of time and memory loading, parsing, rendering, and so on all of
these fonts, even for fonts that weren't very actively used. So the X
people decided to offload a lot of this work to a separate daemon, the
X font server (
although in the usual manner of X they left all of the direct server
side font rendering code intact too. An X font server could (in theory)
be isolated from the X server and if necessary restarted independently;
all of the hairy and CPU consuming code for scalable font rendering
could be parked in a process in it, and so on. The X font server could
handle all font formats that the X server could, and thus could render
all XLFD fonts for the server. Although the X server delegated actual
font rendering to another process, X font handling was still done in the
server; clients still just told the server 'draw text X in font Y'.
xfs could be pointed to exactly the same font directories
as the X server had previously been using directly.)
The next evolutionary step in X font handling was to move it to the client side, which marked (and marks) a stark division in X font handling. This is XFT and 'XFT fonts'. XFT is to a significant degree glue; it uses FontConfig to translate from font names (and attributes) to actual concrete font data files, then FreeType to turn text into picture data and draws the picture data using various X bits.
Technically and theoretically XFT and its pieces still support old X bitmapped fonts. Practically they do not; XFT and XFT-using programs really expect fully scalable fonts, generally ones with a wide glyph selection, and have basically no patience or tolerance for bitmapped fonts that are available in only a few point sizes with only a few glyphs. With heroic work in FontConfig configuration files you can sort of get something limping along, but in practice moving to XFT fonts means no more bitmap fonts.
(Yes, I have tried this experiment. It's especially unsatisfactory for 'frankenfonts', ones where the real font is only available in a few pixel sizes and you were already filling in other pixel sizes with substitutes. The XLFD configuration system is much better for this.)
Generally, the system FontConfig configuration will look for fonts in all of the X server font directories with scalable fonts, or at least all of the directories that are considered to include 'good' fonts. This makes scalable XLFD fonts available to modern XFT-using clients, although under somewhat different names.
(TrueType fonts will generally render the same in XLFD and XFT form because the X server and the X font server long ago were set up to render them with FreeType. Any remaining differences in appearance are due to rendering decisions made differently between FontConfig and the X server environment. I'm not sure how older scalable font formats come out, and generally you don't want to use those fonts anyways.)
So today X has two separate font technologies: XLFD fonts and XFT
fonts. XLFD fonts are configured through
xset's font path directives
(the modern coolness is catalogues) and perhaps your
xfs support is still working in your X server, which it
probably isn't). XLFD fonts and font directories
exist only on the X server machine (or perhaps the
xfs machine) and
properly set up font directories have
fonts.alias files that describe their contents. These are the only
bitmap fonts still supported and XLFD bitmap fonts usually work well at
small pixel sizes.
(This is especially true of monospaced bitmap fonts, many of which were extensively tuned for high readability and high density at relatively small pixel sizes.)
XFT fonts are configured through FontConfig. Magic happens, and it happens differently on
different machines. On the good side,
you can generally put new font files into
$HOME/.fonts and they will
automatically be recognized for you. FontConfig has various sorts of
support for font aliases, but they hide out in magic places like the
XML configuration files in
/etc/fonts (if you want to see some of it,
look for how many things in
/etc/fonts/conf.d want to lay claim to be
monospace', the default monospaced font). Most XFT fonts are TrueType
fonts (at least the modern ones that you want to use) and do not work
well at small pixel sizes.
XLFD font support is pervasive in old X programs but scattered and increasingly absent in modern ones. XFT support is the inverse; uncommon in old X programs and old Unixes (such as Solaris), but increasingly common in modern X programs (especially ones that are part of a pervasive environment like Gnome or KDE, where it is ubiquitous), on Linux, and at least partially on other Unix OSes such as FreeBSD. Some programs and frameworks make an effort to support both XLFD fonts and XFT fonts, but many are XFT-only.
(Today's expedition into this swamp was started by Tk 8.5, which can be compiled to support XLFD fonts or XFT fonts but not both at once. You can guess which option modern Linux distributions have picked.)