Comment # 15 on bug 1118557 from Stefan Br�ns

Brokenness on all levels ...

The "Unable to load any usable fontset" is originating from libXt:
https://github.com/freedesktop/xorg-libXt/blob/0659374e8c1a39433f074226a65f29ae6147157e/src/Converters.c#L1023

while "Error: Aborting: no fontset found" originates from libXaw.
Unfortunately, both libs fail to report which font spec they are trying to
match.

libXt tries to fallback to *any* font with PtSize 120, Slant Regular, or
anything else (comma separated list). So when this error occurs, there is
something *seriously* broken, i.e. not even the "*" pattern matches.

The "Warning: Missing charsets in String to FontSet conversion" can mostly be
ignored, when using any UTF8 locale it tries to find fonts covering almost
every charset completely, even DroidSans + DroidSansFallbackFull combined is
not sufficient for this. 


Also, there are several bugs in the X11 encodings handling:

mkfontscale/mkfontdir does not work as do documented/expected.

"mkfontscale -b -s -l is equivalent to mkfontdir."
"-l     Write fonts.dir files suitable for implementations that cannot reencode
legacy fonts (BDF and PCF).  By default, it is assumed that the implementation
can reencode Unicode-encoded legacy fonts."

The actual outcome is exactly opposite - "-l" *disables* the creation of the
"legacy" encodings. This is a bug known for 3 years, see
https://gitlab.freedesktop.org/xorg/app/mkfontscale/issues/3 .

Although the X server is capable of reencoding iso10646-1 encoded PCF fonts on
the fly, it fails to list these fonts as compatible for e.g. 8859-1, which is
used for the C locale. This happens when mkfontdir is called without any
further parameters.


mkfontscale ignores the "-e" parameters for large parts, i.e. it is only used
for generating the "encodings.dir", but not for generating the
"fonts.dir"/"fonts.scale".