・a2ps のマージン
a2ps の再ビルドのついでに、用紙のマージンを調整してみた。 手元で使っている HP OfficeJet ProK550 だと、デフォルトで登録されている A4dj だと上のマージンが広く、 下のマージンが狭いので、これくらいで丁度いいみたい。
# Desk Jet users: bigger margins #Medium: A4dj 595 842 24 50 571 818 Medium: A4dj 595 842 24 40 571 770
・file-roller のデバッグ(その3)
先日の修正ではオプションのパースが終った後、UTF-8になっている remaining_args[] を filename にコピーする際に locale に合わせるように変更していたけど、メンテナ ML で本多さんに「オプション・パース時の設定では?」という指摘をいただいて、 改めて調べてみたらこっちがビンゴだった。
具体的には、main.c で、引数の解析方法を設定している GOPtionEntry options[] は、
static const GOptionEntry options[] = { { "add-to", 'a', 0, G_OPTION_ARG_STRING, &add_to, N_("Add files to the specified archive and quit the program"), N_("ARCHIVE") }, .... { G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_STRING_ARRAY, &remaining_args, NULL, NULL }, { NULL } };
となっていて、&remainig_args は G_OPTION_ARGS_STRING_ARRAY の指定で文字列であると解釈され、 UTF-8 に変換されて返ることになる。一方、この部分を G_OPTION_ARGS_FILENAME_ARRAY としてやると、 &remainig_args はファイル名であると解釈され、locale に応じたファイル名として返ることになる。
確かに、先に引用したマニュアルもきちんと読むと、「string は UTF-8 で返るけど、ファイル名は Glib filename encoding で返る」と書いてあるので、 これが正しい動作だろう。
結論的には、Glib では文字列の扱い(UTF-8)とファイル名の扱い(Glib filename encoding)は異なっているのだけど、 file-roller の作者は、与えられた引数のうちオプション部分のパースが終った残りについて、本来はファイル名とすべきところを、 文字列と考えてしまった、ということなんだろうな。
まぁ、ASCII な世界とか UTF-8 な世界だと、ファイル名と文字列のエンコーディングは一致するから両者を混同しても問題にはならないので、 露呈しにくい類いのバグとは言えそうだ。
今回は久しぶりに C のソースコードのデバッグをしてみたけど、あちこちにバラまいた printf 文の出力を手がかりに、いくつもの仮説を作っては壊し、 転びまろびつしながら問題箇所を絞り込んでいって、最終的に今までの断片的な情報がそれぞれの場所に収まって、ジグソーパズルの図柄が表われる、 というのは問題解決の醍醐味だなぁ。この "eureka!!" 的な快感が癖になってしまって、この世界から抜けられなくなってしまっている気がする(苦笑