KANOU Hiroki
kanou****@khdd*****
2005年 5月 1日 (日) 10:25:46 JST
狩野です。
岩井さん、問題点の報告ありがとうございます。私はプログラムの読み書き経験が
乏しいので、他にもいろいろ変なことをやっていると思います。お気づきの点が
ありましたらどしどしお知らせください。
> 1. fontforge/autotrace.c の FindLispName() について、eaccess(2) をサポー
> トしていないプラットフォームのために、configure.in で AC_CHECK_FUNC
> を使って eaccess の有無を判別させた方が良いのではないか?
これですけど、eaccess() の移植性に問題があるのであれば使用をやめて、
単に access() を使うことにしたいと思います。FontForge を setuid bit
を立てて実行することはまったく推奨できませんので。
> 2. サンプルファイル(prim-sample.l.gz) を開こうとすると fontforge/sfd.c
> の utf7_enc() で SIGSEGV になる。utf7_u_strcpy() で確保している buf
> が少ないのではないか?
unichar_t は uint16 でした。明らかに足りてませんし、ここのサイズは
UTF-7 の使用に依存する値であって、内部のデータ型の sizeof とは関係ない
ので (たとえ足りていても) バグですね。
> 2. については、Unichar 一文字毎に base64 エンコードに出たり入ったりす
> るとすれば、16 ビット を 6 ビット毎にエンコードして 3 + 前後の'+'
> '-' の一文字当たり最大 5 バイト必要なように思いますが、必要な文字数
> の最適な出し方はちょっとわかりません。
RFC2152 をざっと確認してみました。、エンコードする場合は 3 バイト と
先頭の '+' で最大4 バイト (サロゲートペアは個別にエンコード)、 '-' が
必要なのは "--" ('-' を表す。エンコード部の直後の '-' はデコード時に
除去される) と"+-" ('+' を表す) の場合のみだそうです。
現在の実装でも文字列末尾に '-' をつけてはいないので、unichar_t の字数の
4 倍のバイト数を確保すれば十分だと思います。
ところで、本当は文字名は漢字文字列のままで保持しておいて書き出し時だけ
エンコードしたいんですが、ウィンドウタイトルに日本語文字列がうまく表示
できていないので、文字名をエンコードしています。
(gdraw/gxdraw.c:GXDrawSetWindowTitles() が動かない理由と修正方法が
分かる方がいらっしゃいましたら教えてくださると幸いです)。
狩野 宏樹 <kanou****@khdd*****>