(2006年6月4日更新)
私はWindowsプログラマのためのLinuxプログラミング 〜GTK+とWindowsAPIの比較〜やGtkIMContextの使い方のような文書を書くのと同じような感覚で、2006年2月頃に「GTK+/Glibの内部の文字符号化方式」という題名で文書を書きました。せっかく文書を書いたので、どこかに投稿してみようと思い、Linux Conference 2006 論文募集に応募しました。
昔、Video for Windowsに関する文書を書いたときには、世間から反応が結構ありました。最近の文書はこんなマイナーな文書は誰も読まないだろうと思いつつ文書を書いているので当然といえば当然ですが、最近の文書には反応が皆無です。こんなマイナーな内容では採用されることもないだろうと思っていたのですが、意外にも採用の通知がきました。2006年04月24日のMatzにっきのU-20プログラミングコンテスト実行委員会によると「応募系は低調」のようです。公開された論文発表プログラムを見たところ前年に比べて発表数が減っているので、応募数が少なかったというのは間違いないようです。
しかし応募数が少なかろうと何だろうと、プログラム委員会が採用って言ったのだから私の論文は一定の品質は越えているということです。それにどうであれ応募しない人に比べれば私の方が上なのは明らかです。
正直、本当に私でいいの?と思っているのですが、これも良い機会なのでやってみます。なお私は講演の経験が皆無なので、当日の講演が上手くできるか不安もであります。
採用通知のメールで査読コメントを頂きました。
プログラム委員会より、以下のコメントが届いておりますので、カメラレディ及びプレゼンテーション資料作成の際に参考にしていただければ幸いです。--以下、コメント--
- デスクトップ環境のライブラリである GTK+/GLibについて、ファイル名の取り扱いに関する解説として有用だと評価できます。いくつか改善した方が良い点があります。下記にプログラム委員からの改善提案を述べますので、改善の検討をお願いします。
- print系APIの章だけが浮いているので、内容をファイル名の扱いに絞ることが適切だと考えられます。タイトルの変更も検討してください。
- 論文としての構成を見直し、章−節の階層構造を取るなど検討ください。
- 扱う論点を明確にして、問題点の指摘だけでなく、改善案／解決策の提示、指針と展望があることが望ましいと考えます。検討ください。
- 参考文献の書式を論文の形式としてください。
- この他に、下記のコメントがありました。
- Windows は、少なくとも初出のときには "Microsoft Windows" としてほしい。
- 「文字符号化方式」といったときにCES (Coded Encoding Scheme)と CCS (Coded Character Set)と区別してない(できてない)が、明確に区別した方が良い
- OSに関する相互運用性として、コロンの扱い、スラッシュやバックスラッシュの扱い、についても言及が欲しい。
- ここでまとめられたGTK+/GLibのファイル名処理の問題について、実際のアプリケーションではどうなっているのか（回避されているのか、そのままで問題が顕在化しているのかなど）という点まで膨らませても面白いと思います。
- 現状、もしくは将来どのようなファイル名エンコーディングにすればいいのか といった指針か提言はないでしょうか? リムーバブルメディア上のファイルシステムとかネットワークごし(sambaとかnfsとか)とかも考慮してどうするのが最も問題がすくなそうかとか
査読コメントを受け、下記のように変更しました。