On Sun, 4 Jan 2004, Ross Boylan wrote: > Well, I'm going slowly nuts here. To get to the key point first, xrdb > shows that xterm's font is set to helvetica. However, I am completely > unable to find where that happens. One clue is that under KDE2 I have > the bad font, while under AfterStep things are "normal" (i.e., using > fixed).
The desktop configurations usually use xrdb to merge resource settings. (I don't do this, but occasionally have to rummage around finding what's been changed). The manpage for xrdb is helpful in listing those. Also appres, e.g., "appres XTerm". (It's not clear at what point you're starting). > On Sun, Jan 04, 2004 at 10:21:27AM -0500, Thomas Dickey wrote: > > On Sun, 4 Jan 2004, Ross Boylan wrote: > > > > > With help from the tips here, I've managed to build a debug version of > > > xterm. > > > > > > This shows the font being used is > > > -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso10646-1 > > > > That's probably from an X resource setting that looks like > > > > *VT100*font5: -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso10646-1 > Do you mean that literally font5 is the default font, or was that just > suggestive? At any rate, looking in my .Xresources, suggestive - I noticed that the fontsize happened to be close to one of my resource files' entry for font5. The detail I was concerned about was whether a second "*" in the resource would match the wrong font value. > UXTerm, which it's possible I'm using, has uxterm is a shell script that runs xterm with its class set to "UXTerm", so it uses this particular resource file. Current (since patch #182) xterm puts the same information in "XTerm" with a ".utf8fonts" level, so it's accessible at runtime. > > The second "*" is redundant and will cause current xterm to produce a > > different font than older code. See the "XTerm" app-defaults file, > > where it lists the ".utf8fonts" lines. > > I guess that's been broken into UXTerm in my distro? no - "UXTerm" was the way we did it originally. The ".utf8fonts" arrangement is a new twist (that second "*" may become an FAQ item). But since your xrdb output (below) indicates that isn't the case here, it's not an urgent problem. > Is there a good way to find out what the sequence of call-backs is? Is > it sufficient to put a break on VTInitialize? Maybe - I use traces for most debugging of xterm. VTInitialize is in the parent process, so gdb probably can be helpful here. > But xrdb -query returns > xterm*Font: -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso10646-1 > xterm*background: #ffffff > xterm*foreground: #000000 > xterm.SimpleMenu*background: #eaeaea > xterm.SimpleMenu*font: -adobe-helvetica-medium-r-normal--18-180-75-75-p-0-iso8859-1 > xterm.SimpleMenu*foreground: #000000 > > This is also kind of odd, because there are many more resources set > for xterm in app-defaults. xrdb is concerned with the root window - which happens to be the resources which would be set by KDE. Offhand I don't know which file to look in I simply grep through the files which are read at startup when I need to know (takes only a few seconds ;-). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
