sb> Mark Moll <mmoll(a)cs.cmu.edu&gt; writes in xemacs-beta(a)xemacs.org: sb> m2ps has never to my knowledge worked with XEmacs. I believe that ETL (the Mule developers) has abandoned it at FSF request in any case. sb> There is a hacked version of ps-print.el to handle Japanese sb> (assuming a postscript printer that can deal with Japanese), sb> but it hasn't been integrated yet. If you're referring to the Japan-localized version, this can't handle Mule text in general, and does require a Japanese Postscript device (Ghostscript with appropriate fonts will do). If you're referring to the alpha version of ps-print.el for Mule that was on the ETL site a few months ago, it was somewhat FSF Emacs 20.3-dependent, but I didn't and don't understand exactly how. (Specifically, it used the functions "string-as-unibyte" and "string-as-multibyte", which amount to using the string as an C-style union of a multibyte Mule string and an array of uninterpreted bytes.) However, simply defeating these (I forget the details, probably I turned them into identity operations) allowed printing of Japanese text. (It is possible that those hacked functions were simply not called at all for the examples I tried, though, so this is not yet a Mule postscript formatter for XEmacs.) It does _not_ require a Japanese-capable Postscript printer, although it is presumably much faster if Postscript fonts are available. What it does is to convert X11 BDF fonts to Postscript images, and uses those to print non-ISO8859-1 fonts by default (this is configurable to use the fonts you have). Now that I have a copy of the preprint of the Elisp Manual for FSF Emacs 20.x, I should go back and see. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091