UTF-8で書かれた日本語テキスト, テキストファイルをPostScriptに変換する方法(2019/11)

gnome-u2ps があったのですが開発が停滞しており、debianからはパッケージがREMOVEDになってしまい、その後……(2019/11/4 gnome-u2psに関する追記あり)

・gedit からファイルに印刷する

geditでテキストファイルを表示してファイルに印刷する、という方法があります。 CLI操作が苦手って方がよくやるようです。 psもpdfも作れるようですので、重宝している方も結構いらっしゃるのかも？

・paps (+nkf)

UTF-8で書かれたテキストファイルを pango ライブラリ を用いてレンダリングし、 PostScriptファイルにするフィルタです。 debian のパッケージにはUTF-8で書かれた多言語テキストファイルの例（/usr/share/doc/paps/examples/small-hello.utf8）があり、これを変換してみると便利さがよく分かります。
$ paps --header /usr/share/doc/paps/examples/small-hello.utf8 | ps2pdf - > testsmallhello.pdf $ pdffonts testsmallhello.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- Helvetica Type 1 Standard no no no 8 0
sample-hello.utf8 には日本語の半角カナが含まれるのですが、これがきちんと半角カナのまま変換されるのは、なかなか強力ですね。
レンダリングをpapsがやり、元となる文字列が何であったかという情報を含みません。そのため、ps2txtでテキスト部分だけ引っ張り出す、みたいなことも出来ません。pdfもにおいても、本文をpdfリーダーで取り出せないものが出来ます。

印字フォントを変更するには、fontconfig で認識しているものを使いますが、文字サイズの変更だけでも受け付けるようです。デフォルトは "Monospace 12"となっていますが、実体はシステムによって微妙に違うでしょう。 $ fc-match "Monospace" VL-Gothic-Regular.ttf: "VL ゴシック" "regular" $ paps --header --font="8" /usr/share/doc/paps/examples/small-hello.utf8 | ps2pdf - > testsmallhello-8.pdf $ fc-match "Serif" ipam.ttf: "IPA明朝" "Regular" $ paps --header --font="Serif 14" /usr/share/doc/paps/examples/small-hello.utf8 | ps2pdf - > testsmallhello-ipam14.pdf

日本語のテキストファイルを印字する場合は nkf を併用します。nkf --guessを使って UTF-8(LF)などと返ってくるなら、そのまま変換すればよいですが、それ以外の場合はパイプを使ってしまえばよいでしょう。 $ nkf --guess samplejp.txt Shift_JIS (CRLF) $ nkf -wd samplejp.txt | paps --header | ps2pdf - > samplejp.pdf $ pdffonts testsmallhello.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- Helvetica Type 1 Standard no no no 8 0

DebianにもUbuntuにもパッケージがあり、これが一番安定しているようです。RHELのナレッジベースでも紹介されていますね。

・nkf + e2ps

　e2psにはバグが多いのですが、それでもdebianパッケージなどに入っていることから利用者が若干いらっしゃるようです。e2ps は EUC-JP を受け付けて PostScript を作るものなのでnkf -edなどとした変換が必要になります。

・nkf + a2ps-j (Perl版a2ps)

　日本語テキストファイルをPostScriptにするプログラムには他にも a2ps-j (a2ps perl版) がありますが、perl 4時代のスクリプトなので、MacPortsや各種BSDパッケージなどではパッチを当てたり、色々対応しながらやってらっしゃる方もおられるようです。

https://svnweb.freebsd.org/ports/head/japanese/a2ps/
https://www.uconst.org/blog/archives/437

　個人的に注目しているのが、a2ps-j をUTF-8対応させる、以下のブログのパッチです。開発者さんにおかれましては、このパッチのライセンスを再利用しやすいものに設定していただけますと、各OSでのパッケージとして採用が進むと思いますので、何卒よろしくお願いしたいです。

a2ps Japanese UTF-8 patch (日本語 UTF-8 パッチ)
http://zyushimatsu.cocolog-nifty.com/blog/2014/12/a2ps-japanese-u.html

　なお、GNU a2ps や GNU enscript は日本語がダメそうなままです。つらい。

 (2019/11/4) コメントいただいておりました。
gnome-u2ps が gitlab で復活しているようです。
https://gitlab.com/gnomify/u2ps

で、この記事では紹介していませんでしたが、実は u2ps には数年前に同じ名前で別の人が作ったものがあるんです。
https://gitlab.com/arsv/u2ps

そう考えると、gnome-u2ps は u2ps-gtk とかにしたほうがいいような気もしますね。（ngraph-gtk 的なネーミングセンス……）

nkfのマニュアルを読み違えていた

nkfのマニュアルには、改行コードを変換するオプションの指定方法として、こんなふうに書かれています。
-L[uwm] -d -c Convert line breaks. -Lu -d unix (LF) -Lw -c windows (CRLF) -Lm mac (CR) で、これを見て、 $ nkf -Lu -d source.c こうやって使うのかなあ、なんで -d が必要なんだろうなあ、と思っていたのですが…… $ nkf -Lu source.c もしくは $ nkf -d source.c という意味だったのですね。 nkf --helpで表示されるメッセージには、-dや-cの記載がなく、 実際-Luに併記しなくても問題なく動作したので、あれ？　と思ってソースコードを確認したら……
https://osdn.net/projects/nkf/scm/git/nkf/blobs/master/nkf.c static int options(unsigned char *cp) （中略） case 'L': /* line mode */ if (*cp=='u') { /* unix */ eolmode_f = LF; cp++; } else if (*cp=='m') { /* mac */ eolmode_f = CR; cp++; } else if (*cp=='w') { /* windows */ eolmode_f = CRLF; cp++; } else if (*cp=='0') { /* no conversion */ eolmode_f = 0; cp++; } continue; （中略） case 'c':/* add cr code */ eolmode_f = CRLF; continue; case 'd':/* delete cr code */ eolmode_f = LF; continue; 同じだこれ！？ という話。 もしかしたら、こう書いてあれば誤解はなかったかもしれない… -L[uwm], -d, -c Convert line breaks. -Lu, -d unix (LF) -Lw, -c windows (CRLF) -Lm mac (CR) 他にも何箇所かありそうでつらい。

なお、この１文字オプションは他のものと併用できるので、 $ nkf -wd samplejp.txt | nkf --guess UTF-8 (LF) $ nkf -sc samplejp.txt | nkf --guess Shift_JIS (CRLF) つまり、なんかわからんテキストファイルを、 Linux風(UTF-8, LF)にしたいならオプションは -wd とする、 Windows風(Shift_JIS, CRLF)にしたいならオプションは -sc とする、 みたいな形で覚えてしまってもいいのかもしれません。

array環境と角括弧（ブラケット）

　もうarrayは行列の中に線を引くとか例外的なときにだけ使い、基本 matrix (amsmathパッケージ)にしたい、という話。

　行列の記述方法としての是非はちょっと置いておくとして、例えばこんな行列を組版しようとしました。 \begin{equation} \left[ \begin{array}{cc} \mathbf{A} & [0] \\ [0] & \mathbf{C} \end{array} \right] \end{equation} 　ところがこれはエラーになり、組版できません。 ! Illegal unit of measure (pt inserted). <to be read again> > l.9 [0] & \mathbf{C} ? 　面白い？　ことに、これはエラーになりません。 \begin{equation} \left[ \begin{array}{cc} [0] & \mathbf{C} \\ \mathbf{A} & [0] \end{array} \right] \end{equation} 　2 行目以降の 1 列目の要素、が、[ で始まっている場合、 エラーとなるようです。なにかのオプション記述と勘違いしているのでしょうか。

　対処方法は、\hspace*{0pt}[0] のように、 ゼロ幅スペースや空白文字を頭に置く、か、 \left[ 0 \right] などとすることです。
\begin{equation} \left[ \begin{array}{cc} \mathbf{A} & \left[ 0 \right] \\ \left[ 0 \right] & \mathbf{C} \end{array} \right] \end{equation} 大きくならないことが分かっているのに \left[ - \right]を書くのもなあ、と思っちゃいますね。空白文字なら ~ で１文字ですが当然謎の空間が生まれてしまいます。\hspace*{0pt}もちょい長いですね。複数行あったとき投げ出したくなるでしょう。

　ちなみに amsmath パッケージの matrix 系の環境を使えば、これだけで済みます。 \begin{equation} \begin{bmatrix} \mathbf{A} & [0] \\ [0] & \mathbf{C} \end{bmatrix} \end{equation}
とても、楽。

　array環境は行列の中に縦横線を引くときにだけ使い、基本的には amsmath の matrix 系で済ませていいと思います。

余談：もしかしてtabularもダメかな？　と思って試してみたらやっぱりダメでした。 \begin{table}[h] \centering \begin{tabular}{ccc} A & B & C \\ D & E & F \\ \hspace*{0mm}[A] & H & I \end{tabular} \end{table} ゼロ幅スペースを入れてエラーを回避していますが、お試しの際は \hspace*{0mm}を省いてみてください。 array のときと同様に、 Missing number, treated as zero.などと、 何かのオプションと勘違いしたエラーを出してきます。