ラベル UNIX の投稿を表示しています。 すべての投稿を表示
ラベル UNIX の投稿を表示しています。 すべての投稿を表示

2019年6月17日月曜日

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)があり、これを変換してみると便利さがよく分かります。

sample-hello.utf8 には日本語の半角カナが含まれるのですが、これがきちんと半角カナのまま変換されるのは、なかなか強力ですね。
レンダリングをpapsがやり、元となる文字列が何であったかという情報を含みません。そのため、ps2txtでテキスト部分だけ引っ張り出す、みたいなことも出来ません。pdfもにおいても、本文をpdfリーダーで取り出せないものが出来ます。

印字フォントを変更するには、fontconfig で認識しているものを使いますが、文字サイズの変更だけでも受け付けるようです。デフォルトは "Monospace 12"となっていますが、実体はシステムによって微妙に違うでしょう。

日本語のテキストファイルを印字する場合は nkf を併用します。nkf --guessを使って UTF-8(LF)などと返ってくるなら、そのまま変換すればよいですが、それ以外の場合はパイプを使ってしまえばよいでしょう。

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 的なネーミングセンス……)

2019年6月15日土曜日

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

nkfのマニュアルには、改行コードを変換するオプションの指定方法として、こんなふうに書かれています。
で、これを見て、 こうやって使うのかなあ、なんで -d が必要なんだろうなあ、と思っていたのですが…… という意味だったのですね。 nkf --helpで表示されるメッセージには、-d-cの記載がなく、 実際-Luに併記しなくても問題なく動作したので、あれ? と思ってソースコードを確認したら……
https://osdn.net/projects/nkf/scm/git/nkf/blobs/master/nkf.c 同じだこれ!? という話。 もしかしたら、こう書いてあれば誤解はなかったかもしれない… 他にも何箇所かありそうでつらい。

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

2019年5月13日月曜日

e2ps の修正パッチを一段落させた

 Linux などで日本語テキストファイルをPostScript形式に変換するソフトウェアの一つに e2ps があるのですが、いろいろバグが多くて困っており、一昨年くらいからちまちまと直したりしていました。
http://taraijpn.blogspot.com/2017/06/e2pspatch.html

 とりあえず Debian BTS で公開されているバグを直すところまで出来たので改めて紹介します。修正点は以下の通り。
  • フォントリストの文字型配列がコンパイル不能な書き方だった点を修正。
    • 各ディストリビューションで対応されています。
  • 用紙サイズのポイント数を PostScript の仕様で使われている数に合わせて修正。
    • 一部ディストリビューションで対応されています。
  • 生成される PostScript が EPS だった問題などを修正。
    • これでようやく fixps に怒られずに済みます。
  • 出力したページ数が誤っていた問題を修正。
    • ja_JP.EUC-JP 環境以外で動いているときに起こる問題でした。
  • ヌル文字から始まるテキストファイルが与えられるとクラッシュする問題を修正。
    • これは  https://bugs.debian.org/715852 で報告されていたものです。ヌル文字しかない、もしくはヌル文字から始まる(という意地の悪い)テキストファイルを印刷しようとすると起こる問題です。
  • 複数のファイルをまとめて変換すると、他のファイルの印刷末尾に余計な文字列が含まれる問題を修正。malloc を全て calloc に書き換えた。
    • e2ps README.euc README.english などとして出来たファイルを見たとき気づきました。環境依存?
  • Letterサイズで2面付け(-p2, -l2)を行うと用紙をオーバーする問題を修正。
    • 用紙のアスペクト比を維持するか、アスペクト比を歪めて紙面を広く使うか、どちらか悩んだ結果、前者を取りました。本来であればマージンを調整すべきところなのですが、それは全ての用紙サイズで考えないといけないことなので棚上げ。
  • PostScript の作者 ( %%Creator: ) は e2ps であるものとした。
    • CREATOR は help で使ってたので手を入れました。

 以上の内容を、patch1 として公開しました。(2019/5/14 patch1タグを打ってあります。
https://gist.githubusercontent.com/taraijpn/ea10ff9e908befafab7cff719f26dd20/raw/9a4a6fd502958a0e87db364174cbc331d07055be/e2ps-4.34.patch


 実はもう少しやらないといけないことがあって、
  • 変数の型を整理する。
    • unsigned char を使わないようにする。そもそも string.h で読んでいる関数と合わず warning が出ます。
    • unsigned char や signed char といった型は使わないようにして、コンパイラの警告をなくす。
  • 読み込めるファイルサイズを制限する。(2GB程度の予定)
    • unsigned long を size_t に直したらえらいことになったので。
 機械的な置き換えで問題ないかと思ったのですが、そんなに甘くなかった。sjisの変換に失敗する、とか、READMEにある他アーキテクチャ対応に悪影響が及びそうな気がするので、ちょっと止めてあります。とりあえず patch1 の上流での採用を目指したいところ。

 なお上流への連絡は、WebページにあるCGIで掲示板への書き込みやメールの送信を試みましたがいずれもエラーで動かず、2015年に公開されていたWindowsのプログラムにあるreadmeにメールアドレスが掲載されていたので、そこに送っています。果たして無事届いていますでしょうか……

2017年6月5日月曜日

e2psのpatchを作ってみた

日本語を含むテキストファイルを PostScript形式に変換するプログラムの一つに、 e2ps があります。LinuxのディストリビューションやFreeBSDなどにもパッケージがあったりしますね。

オリジナル: http://wtpage.info/wtseries/unix.html#e2ps
Debian: https://packages.debian.org/ja/stretch/e2ps
FreeBSD: http://www.freshports.org/japanese/e2ps/

で、色々あってこれを使ってみたのですが、どうにも動きがおかしい。
というわけで patch を作ってみたわけです。
https://gist.github.com/taraijpn/ea10ff9e908befafab7cff719f26dd20

どれくらい需要があるのか分かりませんが、とりあえず公開しておきます。

何がおかしかったかは以下の通り。

1)出力ページ枚数のカウントがおかしい。
2ページ以上になっても「One page was outputed」になる。1ページのときは「 1 pages were outputed.」って何故に複数形??

2)複数ページを出力するPostScriptなのに、何故かEPSだと言い張る。
おかげで psset に出来上がったファイルを渡すと、(pssetが内部で呼んでいる) fixpsから「fixps: DSC broken.  gs will be asked a full rewrite of the file.」と言われ、正しいPostScriptと認識されず、きちんと動かない。

3)内部で持っている用紙のサイズ(ポイント数)がおかしい。
なんでこんな数値にしたんだろう。複数面付けするときの計算の事情?

4)オリジナルのソースコードで何故かコンパイルが通らない(うちでだけ?)
ps-font.c に、gsFonts という静的配列の宣言があるのですが、さすがにこれはコンパイル通らないんじゃあ……でもFreeBSD portsmonでは何故かビルド出来てる……何故だ……
http://portsmon.freebsd.org/portoverview.py?category=japanese&portname=e2ps
※FreeBSDの ports では、ps-font.c の内容を修正するための sed コマンドが Makefile 側に書かれていました。どおりで files/ の中を見ても分からないわけだよ!
buildしたログで気づきました orz

===>  Patching for ja-e2ps-4.34
===>  Applying FreeBSD patches for ja-e2ps-4.34
/usr/bin/sed -i.bak -e '/Times-Roman$/,/^Gothic-Medium.Katakana$/{s,$,\\,;}' /usr/ports/japanese/e2ps/work/e2ps-4.34/ps-font.c


続き:https://taraijpn.blogspot.com/2019/05/e2ps.html

2014年5月16日金曜日

nohupはどこにあるのか?

tcsh の場合 where を使ってみると、こうなります。(Debian Linuxで試しています。)
% where nohup
nohup is a shell built-in
/usr/bin/nohup
/usr/bin/X11/nohup
一方 bash の場合は where が無いので which -a を使ってみる。
$ which -a nohup
/usr/bin/nohup
/usr/bin/X11/nohup

というわけで、tcshのnohupはシェルビルトインコマンドであり、bashのそれは外部コマンドなのです。
そして挙動ですが、tcshの場合、manpageによると
デフォルトでは、シェルの子供たちもそうしますが、 シェルは終了時に HUP を子供たちに送りません。 hup はシェルが終了時に 子供に HUP を送るようにし、 nohup は子供がHUP を無視するように 設定します。
とのこと。一方bashの場合はshoptで確かめます。
$ shopt huponexit
huponexit       off
あれ? いずれにせよ、バックグラウンドジョブにhupが渡らないように見えます、 nohup無くても困らないんじゃない? などと思ってしまうのですが、実はそんな簡単な話でもないようです。

 技術 / UNIX / なぜnohupをバックグランドジョブとして起動するのが定番なのか?(擬似端末, Pseudo Terminal, SIGHUP他) http://www.glamenv-septzen.net/view/854

詳細についてはこちらの記事をお勧めします。勉強になります。