From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: jay@m5.chi.il.us (Jay F. Shachter) Newsgroups: gmane.emacs.help Subject: =?ISO-8859-1?Q?Answer_to_the_"Caf=E9_Am=E9ricain"_problem:?= =?ISO-8859-1?Q?_diplaying_latin-1_hyperascii_characters?= Date: 3 Dec 2002 07:14:38 -0800 Organization: http://groups.google.com/ Sender: help-gnu-emacs-admin@gnu.org Message-ID: <6525a5d7.0212030714.47277179@posting.google.com> NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1038928528 8553 80.91.224.249 (3 Dec 2002 15:15:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2002 15:15:28 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18JElj-0002Dg-00 for ; Tue, 03 Dec 2002 16:15:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JEmO-0003yk-00; Tue, 03 Dec 2002 10:16:08 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 49 Original-NNTP-Posting-Host: 24.148.17.110 Original-X-Trace: posting.google.com 1038928478 22134 127.0.0.1 (3 Dec 2002 15:14:38 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: 3 Dec 2002 15:14:38 GMT Original-Xref: shelby.stanford.edu gnu.emacs.help:107695 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:4245 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:4245 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