Bug 130225

Any chance to figure out which change in XTerm.ad is responsible for this. AFAIK we don't have any Windows + Exceed available for testing here.

First of all, I could do the testing here, this would be no problem. I'll try to find more details on how to fix this problem. What I can provide immediately, is some more info on the font negotiation problem. Here is a small snippet of the socket writes from the xterm to the X-Server:

======================8<===================================
write(3, "-\0\20\0\256\1@\0003\0\24\0-Misc-Fixed-bold-R-*-*-13-120-75-75-C-60-ISO10646-1-/5\2\0\256\1@\0", 72) = 72
write(3, "-\0\22\0\257\1@\0;\0\24\0-misc-fixed-medium-r-normal-*-13-120-75-75-c-120-iso10646-1\0/0\2\0\257\1@\0", 80) = 80
write(3, "-\0\20\0\260\1@\0004\0\24\0-Misc-Fixed-bold-R-*-*-13-120-75-75-C-120-ISO10646-1/0\2\0\260\1@\0", 72) = 72
write(3, ".\0\2\0\260\1@\0-\0\24\0\261\1@\0A\0Fi-misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1\0@\0/-\2\0\261\1@\0", 96) = 96
======================8<===================================

These four write commands occur in an endless loop one after the other. I'll try to figure out more details on this problem

Created attachment 55178 [details]
diff to /usr/X11R6/lib/app-defaults/XTerm

When applying this minmal change to /usr/X11R6/lib/app-defaults/XTerm the xterm starts at least also with Hummingbird Exceed.

I'm not sure whether this patch solves all the problems with the fonts, but the xterm starts at least using this configuration.

Hmmm ... can you switch to size "Medium" with your patch? Use 
"Ctrl-L + RigthMouse" for this.

Yes, I can switch to Medium. However, the size of the font is the same as in the Default setting. I've also tried all the other size options and all I've tried seems to work.

I've just noticed that "xterm" issues the following warning on the command line, when opening the "Ctrl-L + RightMouse" menu:

Warning: Missing charsets in String to FontSet conversion

> Yes, I can switch to Medium. However, the size of the font is the same as in
> the Default setting.

... which is intentional. It's strange that switching to this font works, but the initial load of this font does not work.

> I've just noticed that "xterm" issues the following warning on the command
> line, when opening the "Ctrl-L + RightMouse" menu:
>
> Warning: Missing charsets in String to FontSet conversion

Maybe we see a fallback to another font here ...

Is there anything I can test or do? Any advices?

Yes, the output of "xlsfonts" won't hurt (attachment!).

Created attachment 55193 [details]
output of xlsfonts

The *only* unicode font in your "xlsfonts" output is:

-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

Probably it would work if you would install the missing unicode fonts.

I know, that there is a chance to fix this problem by installing more fonts in the X-Server. However, we have very many Windows users at our site, who access the SuSE boxes using Hummingbird Exceed. An installation of additional fonts at the X-Server side would require a software configuration change for every Windows user, which is just impractical. (The Windows software configuration is done by the CIO department, whilst the Linux configuration for our computers is done by myself)

We'll try to reproduce. Stay tuned.

I took the liberty to assign this to Stefan ;)

Just a small comment: I'm almost sure that Hummingbird is interested in interoperability with SuSE Linux, so I assume that you would get at least a free copy of Hummingbird Exceed for testing purposes if you'd ask for. May be they'd also provide support for interoperability tests.

When reducing our fonts to the one you have available I'm getting fatal problems.

X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  15
  Current serial number in output stream:  16

I simply don't know what to do here. We're using this xterm configuration since some years now and you're the first one to complain. Do we need to make
our font configuration much worse just to make you happy?

When we started to use Linux as an alternative OS, a colleague had installed RedHat Linux. We never had problems with fonts with RedHat and Exceed. Then I decided to switch to SuSE and we got severe fonts problems with gvim and xterm. The gvim in the SuSE configuration showed up with strange large fonts and the Xperf went so slow that one could almost watch the appearance of every text line in gvim. In short, the gvim was just unusable in this configuration. Also xterm showed up with ugly fonts, but this time the font was very small and many characters showed up as empty boxes.

To summarize up to this point: We had no problems with RedHat, but gvim and xterm were just unusable with SuSE in our setup!!!

To solve these problems, I was always building my own "gvim-special" (using athena gui) and always patched "/usr/X11R6/lib/app-defaults/XTerm" to get them usable, which is somewhat anoying. Starting with SuSE 10.0, the problems went even worse as "xterm" didn't start at all anymore. So I digged into this problem again and discovered that a SuSE-patch is causing all that trouble (at least in the case of xterm). The vanilla xterm is working without problems.

As I'm sure that I'm not the only user in the world, who is accessing Linux via Exceed, I thought you might be interested in solving these problems. 

What about the small patch I had provided?

Sure, when you don't care about UTF-8 support (or i18n in general) the vanilla xterm configuration works great.

About your patch. Removing the font setttings for the default font is not an option for us. You know what is exactly happening in xterm when you do such things?

To be honest, I'm not really sure what happens when you remove the default font setting. I guess that a default font is used in this case.

I understand that i18n is very important. Isn't there any other chance to reach interoperability with Exceed? 

BTW: I had reported the font problem with GVIM on 9 March 2004: [20040305990000136]

When no default font for single-width characters is defined xterm uses "fixed" as fallback (Latin1 font), which is not an option for us. For whatever reasons
(still needs to be investigated) xterm seems to use the right double-width font, although it's not defined at all.

Does xterm start for you when you only omit the entry for VT100*wideFont and leave the entry for VT100*font active?

Yes, the xterm starts when I omit the VT100*wideFont entry - at least with Hummingbird Exceed 10.0.0.0. 

Ok. Thanks.

This problem is not just confined to Hummingbird Exceed 10.0. Same problem exists with Exceed 8.0. I just switched from FC2 to Suse 10 and ran into the same problem, xterm not coming up at all.

I really don't know how to fix this for your requirements without breaking our default configuration. :-(

I suggest therefore to uninstall the xterm package and compile/install the
upstream xterm version. Of course you can use our openSUSE buildservice to create/provide alternative xterm packages for SUSE 10.0.

--> http://build.opensuse.org/

==> WONTFIX (I'm really sorry)

On the current development version of openSUSE (Factory), xterm starts
for me with the SUSE default setup even if only the fonts
"-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1" and
"cursor" are available:

mfabian@magellan:~$ xlsfonts 
-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
cursor
fixed
mfabian@magellan:~$ locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=
mfabian@magellan:~$ xterm 
Warning: Cannot convert string "nil2" to type FontStruct
xterm:  unable to open font "-misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1", trying "fixed"....
mfabian@magellan:~$ 

You see the warning message that xterm uses the "fixed" font as a fallback.
Of course xterm cannot display fancy languages like Japanese then, but
it basically works (characters in Latin1 like äöüÄÜÖß work as well).

Works in Latin1 locales as well:

mfabian@magellan:~$ LANG=en_US locale charmap
ISO-8859-1
mfabian@magellan:~$ LANG=en_US xterm
Warning: Cannot convert string "nil2" to type FontStruct
xterm:  unable to open font "-misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1", trying "fixed"....
mfabian@magellan:~$ 

I can't reproduce this problem any longer. Even not with xterm of SUSE 10.0.
I used the same font selection as Mike.

# LC_ALL=de_DE@euro LANG=de_DE@euro xterm
Warning: Cannot convert string "nil2" to type FontStruct
Warning: Unable to load any usable ISO8859 font
Warning: Unable to load any usable ISO8859 font
xterm:  unable to open font "-misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1", trying "fixed"....

[ xterm is running ]

This issue seems to be Exceed driven ...

I think as a workaround you could always use "xterm -fn fixed".

Or even use client side fonts via Xft like:

    xterm -fa courier -fs 12

(courier is a scalable font, i.e. this will usually show an xterm with
anti-aliasing) or

    xterm -fa "Misc Fixed" -fs <some size>

if you prefer bitmap fonts.

When using client side fonts via Xft you are completely independent from
the fonts offered by your Hummingbird Exceed X-server.