Wolfgang Slany
How to tweak xemacs to print text files (including Japanese text)?
I think that doesn't work yet from XEmacs, unfortunately.
My Suse 7.3 (german, professional) xemacs with Japanese support sends the text to the apsfilter but a2ps then fails. Sending euc encoded files directly to a2ps produces bakemoji, so my a2ps seems not to support Japanese. Is there a simpler solution than replacing a2ps with a patched version (as in http://www.on.cs.keio.ac.jp/~yasu/jp_a2ps.html) when I have all Japanese packages from Suse 7.3 (german, professional, dvd) installed?
There is the Perl script a2ps.pl by Kazumasa Utashiro
Printing Japanese html pages from netscape works fine, and gs can print latex'ed Japanese files fine.
Then you will be able to print the files produced by a2ps.pl without problems with lpr, or you can directly pipe the output of a2ps to lpr. [...]
Additionally, lpq -lllll reports (first failure after issuing a M-x ps-print-buffer, second failure after pressing the "Print" button):
user@linux:~> lpq -lllll Printer: lp@linux 'y2prn_lp.upp auto'
[...]
Status: IF filter 'y2prn_lp.upp--auto-lp' filter msg - 'a2ps: unknown encoding `ja_jp.sjis'' at 09:43:49.574
[...]
As mentioned in the beginning, the "unknown encoding `ja_jp.sjis'" is also weird
I don't know where this ja_jp.sjis comes from.
since (I believe) I set xemacs to encode files as euc-jp. I may be wrong, but I copied everything from http://www.suse.de/~mfabian/suse-cjk/emacs-and-xemacs.html to my ~/.xemacs/init.el file.
That file sets the default coding system for new buffers to iso-2022-8:
(when (string-match "XEmacs" emacs-version)
(set-default-buffer-file-coding-system 'iso-2022-8))
See 'M-x describe-variable RET buffer-file-coding-system RET' on why
this is a good choice. Setting this to iso-2022-jp or euc-jp instead
causes problems with international mail in Gnus.
But anyway, the buffer-file-coding-system has nothing to do with
your problem. You wrote that you used 'M-x ps-print-buffer'.
This should produce a correct PostScript file independent
of the buffer-file-coding-system. buffer-file-coding-system is only
relevant for IO to disk.
But converting the buffer contents to PostScript happens within XEmacs
where the internal buffer representation is used (internal mule
encoding). This internal buffer representation has all the information
about the charsets used in the buffer and ps-print.el should be able
to generate a correct PostScript file from that. But the current
implementation of ps-print.el in XEmacs is not multibyte capable and
if you have Japanese characters in the buffer, the resulting
PostScript file is just wrong. You can have a look at the PostScript
file by using
C-u M-x ps-print-buffer RET filename.ps RET
This works much better in GNU Emacs (20.7 or 21.x). GNU Emacs has a
'better' multibyte capable implementation of ps-print.el.
Have a look at the top part of
/usr/share/emacs/20.7/lisp/ps-mule.el
to see how to use it.
For Japanese, use
(setq ps-multibyte-buffer 'non-latin-printer)
then you will get PostScript output which uses the fonts in the
Printer or Ghostscript which look nice.
If you want to print all sorts of languages together, you can install
ftp://ftp.suse.com/pub/suse/i386/7.3/suse/gra2/intlfonts-bdf.rpm
and then use
(setq ps-multibyte-buffer 'bdf-font)
Using that you can even print everything displayed on the 'hello page'
(M-x view-hello-file), but bitmap fonts will be embedded in the
PostScript output which will look quite ugly.
Personally I use mainly XEmacs and when I want to print a buffer
containing Japanese I save it to disk first and use a2ps.pl.
Of course it would be nice to have a better ps-print.el in XEmacs
as well and when I find some time I want to try whether I
can make the ps-print.el from GNU Emacs work with XEmacs.
--
Mike Fabian