MURAOKA Taro
koron****@tka*****
2005年 1月 25日 (火) 06:34:22 JST
KANOU Hiroki wrote:
> データをわかりやすくする以前に、FontForge のスクリプトをもっと簡略化・
> 汎用化すれば、ジェネレータにスクリプトを出力させる必要はなくなるの
> ではないかと思います。
同意はしますが、当時のPfaEditのスクリプトの信頼性とか汎用性を考えると
ジェネレータを間に挟んだほうが無難だったということです。EPSの切り出しか
ら何から、全部やらせちゃえば楽は楽なんですが、EPSのインポートがうまくで
きなかった問題や、実行速度&メモリの利用効率という面で不満があって、致し
方なく、です。
# EPSCutなんて書きたくなかったし(苦笑
> Import("./work.d/medium/u00/u*.eps")
> Import("./work.d/medium/u30/u*.eps")
> Import("./work.d/medium/uff/u*.eps")
これって Import("./work.d/medium/u*/u*.eps") みたいな2重のワイルドカード
指定は可能でしょうか? あとばらばらに指定した場合とメモリや速度で違いはあ
るんでしょうか?
# メモリ使用量が少なくなって速度が速くなったらうれしい
> New() の部分を、フォント名や panose などがあらかじめ設定された、グリフを
> 含まないフォントの Open() に置き換えれば、もっと簡潔になりますし、分割
> した EPS を全部同じディレクトリに入れてやれば、Import() は 1 回で済みます。
それは却下です。最終的には1つのディレクトリに6000を超えるファイルがで
き、ファイルシステム(OS)の都合から全体のパフォーマンスが著しく下がりま
す。できれば1ディレクトリにつき数百程度が望ましいので、現行の形になって
います。
今から視野に入れておいていただきたいのは、最終的に6000を超えるファイルを
取り扱わなければならないということです。skeletonをビルドするためのスクリ
プトをcvsに加えておいたので、少しまとまった時間が取れそうなときに、以下
を実行してみれば体験できます。マシンパワー(できれば3GHz以上+1GBメモリが
望ましい)があればそれなりに速く(といっても10分くらい)できます。使用メモ
リと相談しながら、無理っぽいと判断した場合は…途中で実行を止めてください。
$ perl scripts/bdf2eps.pl -fw r -o work.d/test-r bdf.d/mplus_f12r.bdf \
bdf.d/mplus_f12r_jisx0201.bdf bdf.d/mplus_j12r.bdf
$ fontforge -script test_r.pe
$ fontforge -script scripts/2ttf.pe test_r
> 簡便化ついでに一つ村岡さんにお尋ねしたいのですが、codemap で JIS
> エンコーディングをサポートする必要ってありますか? Unicode 限定にして
> しまえばコード変換の手間も省けますし、UTF-8 か UCS-2 で Unicode テキスト
> そのものを書いてしまうようにすれば、見たまんまという意味でこれ以上
> 直感的なデータ形式はないと思うのですが。
それは第一にフォント作成者(coz)さんの利便性のためです。cozさんはすでに
ビットマップフォントの作成において、JISと実際の文字形との全対応を一度経
験されてます。つまり日本語領域についてはUnicodeの直接指定よりもJIS指定の
ほうがしやすい、ということです。
第二にPfaEdit時代に、JISに設定して日本語だけ読み込んでUCSに再設定して
〜ってなこともやってみましたが、Win独自のUNICODEの問題やUCSにしか無い文
字の取り扱いとか、ややこしいことになった経緯もありました。*.peのジェネ
レータを使っているのはそのあたりの事情も込みです。PfaEditのスクリプトに
コード変換など複雑なことをさせるくらいなら、ビットマップ時代にある程度ノ
ウハウが溜まっているPerlで書いたほうが良いねぇ、という判断です。
UCS2 onlyで受け付けたほうがプログラム的に簡潔だ、というのは認めます。と
いうよりも、それで押し通せるならどんなに楽か(苦笑)。でも、プログラム的に
解決できるところは解決したほうが良いでしょう?
--
MURAOKA Taro <koron****@tka*****>