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): xterm-334-2.fc30.x86_64 How reproducible: always Steps to Reproduce: 1.see below 2. 3. 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"
Miroslav, 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? George...
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.
Miroslav, 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, George...
(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? https://kojipkgs.fedoraproject.org//work/tasks/8212/33078212/xterm-344-1.fc30.x86_64.rpm
Miroslav, There's another rpm needed to install this rpm. It looks like dnf has a problem too. "Conflicting requests"? George... 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. Error: 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)
Hm, yes, I forgot about that. You can find all rpms and the source rpm in the same directory: https://kojipkgs.fedoraproject.org//work/tasks/8212/33078212/
Miroslav, 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"
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
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.
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: catalogue:/etc/X11/fontpath.d,built-ins 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.
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).
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/" ?
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).
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.
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.