MURAOKA Taro
koron****@tka*****
2005年 1月 29日 (土) 01:50:24 JST
村岡です。 現在あるのをジェネレータアプローチ、狩野さんが提案されているのをテンプ レートアプローチということで書きます。 KANOU Hiroki wrote: > テンプレートで指定した場合、ループ回しながら readdir() で取ってきては > 1 個ずつ読んでいるようなので、自分でファイル名を書き連ねるよりも OS 側の > メモリ消費が若干減る+ファイル数減少で速くなる程度の差しか出ないの > ではないようです。ご指摘の通り、一ディレクトリに置くファイル数がいちばん > パフォーマンスに影響すると思います。 > > ところで、空のテンプレートについてはどうでしょう? スクリプトからデータを > 追い出すことができて好都合だと思うのですが。 テンプレートアプローチを、手っ取り早い変換&TTF生成の手段として導入するこ とには賛成です。 しかし色々考えたのですが、それ固有の作業について私が担当することは、当分 の間、差し控えさせていただきたいと思い至りました。逆に幅を考慮した切り出 しや、字間情報ファイルからFontForgeへ入力するカーニング情報の取り出しな ど、両方のアプローチに共通して必要な作業については、責任を持って完遂した いと思う所存です。 以下、理由を挙げておきます。 1. まずなにより、私は*.peに通じていないので作業するに値しません 2. また*.peは汎用言語ではないので、習熟する時間を割きたくありません(実際 割くだけの時間もなかったり orz) 3. 加えて現状のテンプレートアプローチには潜在的に以下の問題があります 3-a. (これは簡単に修正可能だと思うし、私的な狙いもあるのでそんなに重要視 はしていません)主にフォント名とかmplus以外のフォントのコンバートも視野に 入れた汎用化が欲しい 3-b. (これは*.peでどの程度解決できるか不明です)1つの文字のEPSを修正した だけでも、ほぼ全文字のImportをしなければならず実行コストが高い 3-bについてジェネレータでは、ターゲットとなる*.sfdと入力の*.epsの最終更 新日時を比較して、必要な*.epsだけをImportする*.peを出力していたと記憶し ています。今はまだ高々100個超のImportですので現在の方法で何とかなると思 いますが、先々この違いが効いてくるはずです。テンプレートアプローチでも同 様の仕組みは必要でしょう。 万が一テンプレートアプローチで3-bが解決できないとなれば、そちらは捨てて ジェネレータアプローチでやるべきですし、できることが確実ならばジェネレー タアプローチは切り捨てて良いと考えてます。 どちらにせよ私としては、テンプレートを使った変換&生成パスについて(という よりは全*.peスクリプト)、*.peスクリプトのcvsへの追加や管理は、狩野さんに お任せしたいのですが、いかがでしょう? -- MURAOKA Taro <koron****@tka*****>
