Today at 12:08, David Sumbler wrote: > If I run Emacs (version 21.3) under X, (a) display correctly, but (b) > appear as hollow boxes. On the other hand, if I run Emacs, as I > usually do, on a console (unicode enabled), (b) display correctly, and > (a) appear as the "replacement character" 0xfffd - exactly the > opposite behaviour to what happens under X.
I usually update my fonts.alias to point all encodings to -misc-fixed-*-iso10646-1 fonts. Basically, I have in my fonts.alias: -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1 and this repeated for each of ISO-8859 encodings (Greek is -7, I think). You can add this for whatever encoding is supported by the font and which you need. Of course, I have -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1 font defined and working, and I set Emacs to use it. > (a) and (b) are meant to be the same, so why aren't they?) Basically, Emacs still wants to use encoding-specific fonts for what it reads in, while it commonly allows you to enter using mule-unicode-* encodings, which then display fine. FWIW, I'm running Emacs CVS (not unicode branch), and I didn't have exactly this problem (I had the problem that Emacs gave preference to -adobe-courier-*-iso8859-1, while I wanted to use -misc-fixed all over), but this solved it for me (and during different phases of testing, I managed to get hollow boxes as well :). Cheers, Danilo -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
