diary/Kojima/2009-08-08
の編集
http://plamo.linet.jp/?diary/Kojima/2009-08-08
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
-- 雛形とするページ --
diary/Template
[[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
タイムスタンプを変更しない
[[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
テキスト整形のルールを表示する