ごうです。 <m3snyofnsk.fsf _at_ appi2.appi.keio.ac.jp>の記事において uchiyama _at_ appi2.appi.keio.ac.jpさんは書きました。 >hironobu _at_ h2np.suginami.removeme.tokyo.jp (Hironobu Suzuki) writes: > >> うーん、それって、レンダリングのメカニズムが悪いのか、それともメカニズ >> ムは問題がないがフォントに用意されている情報が不足で美しいレンダリング >> ができないのか、それともメカニズムもフォントも両方とも問題なのか。 「TrueType のグリフのレンダリング」そのものについては、内山さんの おっしゃっている通り、FreeType 登場後はヒント情報の参照により改善されています。 # 「特許問題」ってのが出てきているけどとりあえずノーコメント # VFlib も最近の版は FreeType を使いますので大分改善されていると思います。 # GhostScript の場合、GS -> VFlib -> FreeType といった2段階利用なので # うまく情報が参照できているかどうかは ??? X からの利用の場合は、さらに X Protocol レベルでの制限がかかるので、 文字のグリフそのものは仮に綺麗にレンダリングできても、メトリック情報が うまく処理できません。 X は、フォントを開いた時点で、そのサイズでの全メトリックを要求する仕様に なっています。フォントのメトリック情報、それからさらにはグリフも文脈によって 変化する場合があり、TrueType はこのような情報を内部に保持させることが 可能なのですが、X ではこの情報を参照させて緻密なレンダリングを行わせる ことは原理的に不可能です。 それから、現在の X-TT の実装は、実用的な速度での運用を行うため、「固定幅」 と指定すると、EM 情報で他の全ての文字の文字のそれを代用させます。この時点で フォントのの持つ、文字単位でのメトリック情報は全て失われています。 あと、X は「縦書き」の 機能を持ちません。縦書き可能な TrueType Font は そのための情報を内臓しており、Windows はこれを参照した縦書きの機能を 提供しています。 >の問題といえるでしょう. FreeType では, ヒントの処理をしているのですが, >今度は, フォントメーカがインストラクションをどの程度作り込んでいるかと >いうフォントの情報の問題にぶつかることになります(あまりきちんとつくり >こんでいないのではないかということを聞いたことはありますが, 実際に調べ >たことはありません). こと日本のフォントについてはあまりつくりこんで無いことが多いでしょう。 フォントを小さい文字で表示してみると相当汚くなりますね。 それなりのサイズでも、MS 明朝と 他のフォントを比較してみるとかなり違いが でます。安い TrueType フォントだと、数十pixel 以下ぐらいのサイズで、ちょこ ちょこドットがとびでてたり、線の太さがかわってしまったりするのが 観察できます。 それから、これはレンダリングにそのもの関することではないですが、「可視性」 という点からみて、X は原理的に「アンチエイリアス」が不可能なので、相当 不利ですね。ヒント情報が無いようなフォントでも、Windows のように アンチエイリアスが有効な場合は擬似的に精度があがるので、気になりにくいです。 -- 渡邊剛 (Watanabe,Go) go _at_ isoternet.org / go _at_ denpa.org
References:
- [fol] Re: X のフォントHironobu Suzuki
- [fol] Re: X のフォントTakanori Uchiyama
- Prev by Date: [fol] Re: Slackware7.0でのX-Wndowについて
- Next by Date: [fol] Re: Laser5 6.0 で起動時 Starting CannaやSendmail のところで長時間止まる
- Previous by thread: [fol] ヒラギノ, 平成, Ryumin (Re: X のフォント)
- Next by thread: [fol] RAID with kernel2.2.14+ide patch
- Indexes:[Main][Thread]