Bug 1679790 - xterm fails to find the requested font
Summary: xterm fails to find the requested font
Alias: None
Product: Fedora
Classification: Fedora
Component: libX11
Version: 31
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-02-21 21:04 UTC by George R. Goffe
Modified: 2020-11-24 15:08 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-11-24 15:08:16 UTC
Type: Bug

Attachments (Terms of Use)

Description George R. Goffe 2019-02-21 21:04:20 UTC
Description of problem:

Attempting to ask xterm to use a different font (see below) gives a message and fails to find the font yet xlsfont thinks the font does exist on this system.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.see below

Actual results:
see below

Expected results:
an xterm widget that uses the requested font

Additional info:

xterm -bdc -cm -fg "$FG" -bg "$BG" -sb -sl 4096 -cr green -ms red -fn '-adobe-courier-bold-o-normal--14-100-100-100-m-90-iso10646-1' -fb "$FOTDb" -title '-adobe-courier-bold-o-normal--14-100-100-100-m-90-iso10646-1' -geometry 0121x0027+"$x"+"$y" -e bash

xterm: cannot load font "-Adobe-Courier-medium-O-*-*-14-100-100-100-M-180-ISO10646-1"

Comment 1 George R. Goffe 2019-02-25 21:04:06 UTC

Here's some interesting information that I just noticed.

I just ran xpdf and specified a font that xlsfonts thinks is on the system. Xpdf FOUND the font. I thought I'd try using that font with xterm. The font appeared to work but, the SAME message appeared about "cannot load font". I noticed that the font that I had tried was NOT the font in this error message!

I looked in the xterm binary but didn't see a font with the name in the error message.

Odd behavior?


Comment 2 Miroslav Lichvar 2019-02-26 08:30:31 UTC
This might be related to the bug #1534475, or its fix. I'm not sure. I'd suggest to try the latest upstream xterm version.

Comment 3 George R. Goffe 2019-02-27 02:57:28 UTC

You're right.

I did a "git clone https://github.com/joejulian/xterm.git" and built it. This binary runs the command above with NO error messages.

Do you know if someone is working on this bug? Perhaps they could be made aware of this "fix"?

Anyway... if you need to close this bug that would be cool with me.

THANKS for your help,


Comment 4 Miroslav Lichvar 2019-02-27 09:02:19 UTC
(In reply to George R. Goffe from comment #3)
> I did a "git clone https://github.com/joejulian/xterm.git" and built it.
> This binary runs the command above with NO error messages.

That repo seems to contain a very old xterm version.

Can you please try this scratch build of the latest version?


Comment 5 George R. Goffe 2019-02-27 19:42:53 UTC

There's another rpm needed to install this rpm.

It looks like dnf has a problem too. "Conflicting requests"?


rpm -ivh xterm-344-1.fc30.x86_64.rpm
error: Failed dependencies:
        xterm-resize = 344-1.fc30 is needed by xterm-344-1.fc30.x86_64

dnf install !$
dnf install xterm-344-1.fc30.x86_64.rpm
Last metadata expiration check: 1:41:41 ago on Wed 27 Feb 2019 09:58:07 AM PST.
 Problem: conflicting requests
  - nothing provides xterm-resize = 344-1.fc30 needed by xterm-344-1.fc30.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Comment 6 Miroslav Lichvar 2019-02-28 09:21:43 UTC
Hm, yes, I forgot about that. You can find all rpms and the source rpm in the same directory:


Comment 7 George R. Goffe 2019-02-28 09:34:29 UTC

I built the source from above and here's what I got:

/tools/xterm/xterm-344# ./xterm -bdc -cm -fg "$FG" -bg "$BG" -sb -sl 4096 -cr green -ms red -fn "$FOTD" -fb "$FOTDb" -geometry 0121x61+1306+0469 -e bash
./xterm: cannot load font "-Adobe-Courier-medium-R-*-*-14-100-100-100-M-180-ISO10646-1"

Comment 8 Ben Cotton 2019-08-13 16:49:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 9 Tomas Korbar 2019-08-26 10:59:11 UTC
Hi George,
I took over maintenance of xterm after Mirek. I found out what the problem here is.
If you do not specify font for wide text, xterm will try to find it by doubling normal font's width.
That will result in for example "-Adobe-Courier-medium-R-*-*-14-100-100-100-M-180-ISO10646-1" if you use -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1.
                                                                            ^^^^^                                                                       ^^^^
It displays error because that font does not exist.
I know that the ISO number is wrong too but the next thing i found out is that if you specify font for wide text with "-fw" option, then this issue will not occur.
So i wanted to provide you a workaround until i figure out what to do with this.

Comment 10 Thomas E. Dickey 2019-08-29 08:35:22 UTC
Tomas Korbor reminded me about this one, suggesting some improvements to the warning message.

However, the actual problem is not in xterm, but (apparently) the changes made to use fontconfig
rather than the font-server utility. The latter supports an "unscaled" property which is used
to obtain bitmap fonts which are scaled by the X servers.  That is seen in the configuration
of Fedora 30, but it does not work.  "xset -q" returns

Font Path:                                                                      

which is a directory containing symbolic links:

> ls -l /etc/X11/fontpath.d
total 0
lrwxrwxrwx. 1 root root 27 Mar  5 21:38  liberation-fonts -> /usr/share/fonts/liberation
lrwxrwxrwx. 1 root root 25 Feb  3  2019  terminus:unscaled -> /usr/share/fonts/terminus
lrwxrwxrwx. 1 root root 27 Feb  3  2019 'xorg-x11-fonts-100dpi:unscaled:pri=30' -> /usr/share/X11/fonts/100dpi
lrwxrwxrwx. 1 root root 26 Feb  3  2019 'xorg-x11-fonts-75dpi:unscaled:pri=20' -> /usr/share/X11/fonts/75dpi
lrwxrwxrwx. 1 root root 25 Feb  3  2019 'xorg-x11-fonts-misc:unscaled:pri=10' -> /usr/share/X11/fonts/misc
lrwxrwxrwx. 1 root root 26 Feb  3  2019  xorg-x11-fonts-Type1 -> /usr/share/X11/fonts/Type1

It's easy to test, using vttest (menu 4: Test of double-sized characters).
In Fedora 30, none of that works.

Comment 11 Thomas E. Dickey 2019-08-31 00:20:57 UTC
I investigated, found nothing to indicate that the problem with Xorg is a known issue.
This should be reassigned to the xorg-server component.

(sure, I'm improving the message itself, but it's reporting a defect in either the Xorg server or the configuration which Fedora provides).

Comment 12 Tomas Korbar 2019-09-02 07:03:01 UTC
Hi Thomas,
i just want to be sure about some things. If fontconfig/xorg-server would work as expected then call to function XLoadQueryFont on fontutils.c:925 with derived name of font would properly return XFontStruct even if that font's .pcf file would not be present in "/usr/share/X11/fonts/" ?

Comment 13 Thomas E. Dickey 2019-09-02 09:11:25 UTC
Something like that.  I'll try to clarify.

The ":unscaled" property tells the font-server (or whatever step of Xlib...Xorg-server handles fonts)
to do scaling of bitmap-fonts to handle certain cases of "missing" fonts.

The font xterm is asking for is derived from an existing font, and it is asking for a trivial (double-width) scaling.
In practice, it could also be asking for a bold version of the normal font.

The reported problem was due to an inconsistency in how the fontWarnings resource
was applied (which I fixed in a commit last week).  But if ":unscaled" had been working
as it had been for about twenty years in other platforms, then the warning would not have
been seen (unless one set fontWarnings to 2).

I did some investigation, supposing that it was due solely to not running the X font-server,
but it appears that some other platforms have done this but made ":unscaled" work as expected.

Given all of that, I think the bug should be reassigned to whatever component of Xorg
is responsible for the behavior (perhaps fontconfig, perhaps xorg-server).

Comment 14 Tomas Korbar 2019-09-02 10:27:39 UTC
Thanks for clarification. Now i believe we have enough information to deal with this.
Reassigning to libX11 component.
Description of issue:
libX11 fails to scale font. As discussed before xterm uses XLoadQueryFont function to get a font which is a scaled version of an available font.
For example if xterm's normal font is -adobe-courier-bold-o-normal--14-100-100-100-m-90-iso10646-1 then xterm will ask for -Adobe-Courier-medium-O-*-*-14-100-100-100-M-180-ISO10646-1 for double width characters. Normal behavior as Thomas described would be that XLoadQueryFont returns scaled font but that does not happen.
I'm not entirely sure if this is a bug of libX11 or this is a fault of some other component so feel free to reassign if i am wrong.

Comment 15 Ben Cotton 2020-11-03 16:51:54 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Ben Cotton 2020-11-24 15:08:16 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.