[[diary/Kojima]]
・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
#comment
・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!!" 的な快感が癖になってしまって、この世界から抜けられなくなってしまっている気がする（苦笑
-この手の作業は面白いんだけど時間がかかるし、そもそも時間をかけても解決するかどうか分からないから、なかなか手を出せないんだよなぁ。 -- [[kojima]] &new{2009-08-08 (土) 20:37:04};
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
