Answer to the "Café Américain" problem: diplaying latin-1 hyperascii characters

[Jay F. Shachter]

I have solved the problem of Emacs's failure to display latin-1 hyperascii
characters -- even though XEmacs was displaying them perfectly -- and in solving
the problem, discovered a fascinating albeit esoteric subtle difference between
Emacs and XEmacs, at least in my computer environment, and perhaps in yours too.

The problem could not have lain in my .emacs startup file, as someone else
quite reasonably suggested, because I use the same .emacs startup file for both
Emacs and XEmacs.  The problem lay with the X resource database, which had a
different value for xemacs.font than for emacs.font.  Consequently, emacs
started up with a font (specifically, "6x12") that does not have hyperascii
characters.  Therefore, Emacs did the intelligent and sensible thing by choosing
ascii characters which resembled the hyperascii latin-1 characters in
appearance, e.g., displaying "é" as "e".

The fascinating and esoteric part is why the X resource database was set up in
this way.  Here's the answer.  The value in the database for xemacs.font was
"-itc-courier-medium-r-normal--10-100-75-75-m-0-iso8859-1".  Now, this string
as such does not appear in the output of xlsfonts, because it is a scalable
font.  The output of xlsfonts contains the unscaled name of the font, which is
"-itc-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1".  Replacing the first
four 0's with 10-100-75-75 produced a fontname which is perfectly acceptable
to XEmacs (and to xfd, for that matter).

Emacs, however, exits with a fatal error when given that fontname, complaining
that "no fonts match" the specified name.  That is why the administrator of
the X resource database gave up on Emacs, and instructed it to use "6x12".

But I found a better solution.  I changed the X resource database so that
emacs.font is now "-itc-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1".
What's the difference between that value and the value that satisfied XEmacs?
Only that the width field is explicitly specified for Emacs to be 60, whereas
XEmacs was satisfied with a 0 in the width field.  Everything is now working
perfectly, Emacs is now using the same font as XEmacs, and it is displaying
hyperascii latin-1 characters beautifully.

The larger, unanswered, question, of course, is why Emacs insisted on a value
in the charwidth field of the fontname, whereas XEmacs and xfd were satisfied
with a zero when the font was a scalable font, and the scaling informating was
available elsewhere.  It is not an XLib error.  I wrote a program that does
an XLoadQueryFont on the fontname used by XEmacs, and the XLoadQueryFont
succeeded, generating the appropriate XFontStruct value.  When Emacs is given
that fontname, however, it complains that "no fonts match" it, apparently
without even trying to do the XLoadQueryFont.

What is the reason for this bizarre behavior?


                    Jay Shachter
                    jay@m5.chi.il.us