Re: mgl2 make failured

[suz@hpc.bs1.fc.nec.co.jp (Koji Suzuki)]

鈴木(康)です。
<39725EF0DC.3C05.BXQ04723@nifty.ne.jp>の記事において
BXQ04723@nifty.ne.jpさんは書きました。

  | お世話になっております。 A.中村です。
  | 
  | On Mon, 17 Jul 2000 10:45:14 +0900 (JST)
  | suz@hpc.bs1.fc.nec.co.jp (Koji Suzuki) wrote:
  | 
  | > Xserver 使っての、フォントコンバータがあっても 話は解決しなかったので、
  | 
  | Xを使うこと自体が、大きめ(^^;の計算機環境ではともかく、
  | hpcmipsにおいては、多少の障壁となるのかな、という感想を
  | 持ちましたです。Xに限らず、コンバータを動かすための前提環境の
  | 手軽度ってのは、常に少しづつの影響因子になりそうですね。

そうですね。他のマシンで フォントを作るか、display を他の Xserver
にして やれば良いのですが、環境依存だし 万人向けではなかったですね。

  | > やっぱり標準フォントは ちゃんと配布しないとダメだなぁと思いました。
  | 
  | そういや「標準フォント」という考え方は
  | ある程度必要でしたね。頭から揮発していました(^^;

「標準フォント」さえクリアしておけば、入れ換えるのは、
コンバータとか使ってやればいいのかなと思いました。

  | > 大きくなるかも知れないのですが、切り離せるような構造をしていれば
  | > mgl が大きくなってしまうという問題は回避できると思います。
  | 
  | fe_hoge.so とかですか？(^^;

make のオプションで切り離せることしか考えていませんでしたが、
そうしても良いかなぁ。

  | ただ、実行時処理が必ずしも楽じゃない重たいフォント形式も
  | 世の中にはあるんでしょうから(TrueTypeとか?)、
  | コンバータのことも別途考えるほうがいいのかもかも。
  | 現状の独自形式フォントって、MGLにとって「軽い」んですよねえ???

メモリ消費の観点だと、swap を使わずに、全部 pageout(というか flush) 
できるので、たぶん軽いんじゃないかと思います。
( しかも、複数プロセスで 共有しても、メモリ消費量増えない)

FONTX 形式だと、コード変換のテーブルをプロセス毎に作ることになりそうなので、
MGL では、メモリ的に重いような気がします。

--
					鈴木　康司 ＠ＮＥＣソリューションズ
					suz@hpc.bs1.fc.nec.co.jp
					TEL 042-333-6465