フォントラスタライズアルゴリズムの公開（1/2）

公的に入手可能な情報のみを使用して、フォントラスタライズアルゴリズムを改善する試み。

翻訳者から

この記事に初めて出会ったのは2008年です。 それ以来、私は翻訳について何度も考えてきました（トピックに関するより良い資料を見つける方法がないため）。そして、トピック「フォントスムージング、アンチエイリアス、およびサブピクセルレンダリング」のディスカッションで、突然、 Habréに元のリンクが表示されました。 これが決定的な要因となり（誰かが資料を参照するため、誰かがそれを必要とすることを意味するため）、作業は最終的に終了しました。



使用されている用語の中には、一般的に受け入れられているロシアの対応するものがありません。 アンチエイリアスをアンチエイリアスとして（Wikipediaが信じており、私もそれに同意する傾向がある）、ヒントとしてヒンティング （私の意見では、ヒンティングはあまり調和的ではなく、一般的な単語ではありません）に変換し、 ラスター化 （フォントに適用）としてレンダリングしますこの用語は、英語のトレーシングペーパーよりも適切であると思われます;「描画」は、私の意見では、あまりにも一般的な概念です）。



これまでスクリーンタイポグラフィのトピックに興味がなかった人にとっては、記事を読む前に上記のリンクをたどり、これらすべての用語の意味を理解しておくと役立ちます。



この記事は2007年に公開され、その中で言及されているWindowsの最新バージョンはVistaです。 それにもかかわらず、記事のほとんどは今日に関連しています：Windows 7では、フォントラスタライズメカニズムはVistaからそれほど遠くなく、インターフェイスをWebプラットフォームに転送する傾向により、異なるオペレーティングシステムのラスタライズの違いに異なるブラウザのラスタライズの違いが加わりました。 したがって、私の意見では、この記事で提示されたアイデアはこれまでのところ関連性を失わない。



スクリーンショットのテキストを翻訳しませんでした。一方で、正しい画像を準備する技術的な能力がありませんでした。他方では、それらのテキストは記事の意味に影響しません。



ロシアのIT業界で一般的に受け入れられているDPIなどの例外を除き、従来は単位をメトリックに変換しようとしています。 さらに、名前は翻訳しますが、会社とその製品の英語名はそのままにします。



翻訳の追加や修正に感謝します。 明らかなエラーやタイプミスについてのプライベートメッセージを書いてください-コメントを詰まらせません。 ありがとう

エントリー

Joel Spolskyの記事「Smoothing Fonts and Subpixel Rendering」 [1]（ Habréの以前の翻訳の同じ記事 、およそTransl。 ）マイクロソフトとApple製品のテキストラスタライズ方法を比較し、Windowsユーザーが気に入らない理由を仮定します。サファリ 彼はこれを、Safariのテキストが過度にぼやけていると言って説明します。 さらに進んで、この問題に関する私自身の経験をまとめたいと思います。 私はデジタルタイポグラフィの専門家ではありませんが、言いたいことがあります。 少なくとも私のアイデアのいくつかは、GNU / Linuxコミュニティに役立つでしょう。



ジェフ・アトウッドは、彼の投稿「フォントのラスタライズ：ピクセルグリッドへのこだわり [5]」で次のように書いています。

「Appleが将来のために現在を犠牲にしている理由がわかりません。 ラスタライズの精度を高く観察しながら、低解像度でヒンティングを使用できないのはなぜですか？ フォントをピクセルグリッドにリンクすることは、誰もが200 DPIの解像度でモニターの画面で壮大な画像を楽しむことができる場合、ほとんど関係がない可能性があります。 しかし、その素晴らしい時が来るまで、ピクセルグリッドにスナップすることで、現在の生活をしている人にとって間違いなくテキストが読みやすくなります。

このように答えます。Microsoftが積極的なヒンティングポリシーを順守している限り、100 DPIを超える解像度のモニターは表示されません。 マイクロソフトの努力により、悪循環から逃れることはできません。



ジェフは、アップル製品で使用されているラスタライズ方法を承認していません。 彼も私には可愛くない。 しかし、Appleの使命は、200 DPIモニターの時代を近づけることでしょうか？ さて、私のバーはさらに高く、300 DPIが必要です。 私の意見では、200 DPIでもヒントを完全に放棄するには不十分です。 それでも、この記事では、Appleの戦略についても強調します。 この記事は長くて退屈に思えるかもしれませんが、現在の状況を注意深く徹底的に分析する必要があると感じています。



ちょっとした陰謀を加えるために、私は先を見ていくつかの例を示します。







ぼやけて見える？ ただし、テキストのサイズに注意してください。 そして、それは完全に読みやすく、滑らかであると同時に明確であることに留意してください。 同時に、標識の形状は完全に保持されます（Arialヘッドセットが使用されます）。



OK、この例はどうですか？







重すぎますか？ 問題ありません、より明るくすることができます。







さらにいくつかの例：











これはジョージアフォントです。 どちらの場合も文字の形状は完全に保持されていることに注意してください。2番目の例では、テキストが意図的に「重く」されています。



しかし、これは単なるデモンストレーションであり、この記事の主なアイデアは次のとおりです。ピクセルグリッドへの水平スナップを拒否できます。 これからは、テキストの水平方向の位置決め精度を1/256ピクセルで使用できます！ テキストの美しい外観を維持しながら、小数値でテキストを水平方向にシフトできます！ この「些細なこと」は実際には多くのことを意味します。 これはどうですか：

• 追加のぼかしを気にすることなく、サブピクセル解像度でカーニングを適用できます。
• 縦横比を維持し、グラフィック要素の境界からはみ出さないテキストを100％保証することで、テキストを好きなように自由に拡大縮小できます。
• 計算されたテキストの幅が、常に画面および紙の画像に対応することを確認できます。
• テキストがぼやける危険を冒すことなく、「人工太字」や「人工斜体」などの興味深いベクトル効果を適用できます。

不可能なように聞こえますか？ わかりました、別の例はここにあります。







よく見てください。 何かおかしいことに気づきましたか？ 各行は1ピクセルの1/10だけ右にシフトされるため、結果として、30行目のシフトは徐々に累積され、すでに3ピクセルになります。 ピクセルグリッドへのクラシックスナップを使用した場合、この例がどのようになるか想像できると思います。



想像できない場合は、次の例をご覧ください。







最も驚くべきことは、ここには驚くほど複雑なものは何もないということです！ 特許を取得することはありません。 私が使用したすべての情報は、公開されているか、現在使用されているフォントラスタライゼーションアルゴリズムについて知っていることから論理的に推測されます。 あなただけの常識と少しエンジニアリングの才能が必要です。 行きましょう。 この記事の最後で、すべてのソースコードを含むデモプログラムをダウンロードして試してみることができますが、最初はこの長い話を最後まで読んで少し忍耐を示してください。

Microsoft、Apple、Adobe、およびFontFocus

かなり厳しい発言から始めます。 マイクロソフトは、世界の他の地域でトリックを演じてきました。 Windows XPでフォントをラスタライズする方法は、エンジニアリングカルチャーが完全に欠如しているため、味が悪くなります。 XPのテキストは鮮明で魅力的に見えますが、完全に間違っています。



ちょっとしたテスト。 Times New Romanヘッドセットによって入力され、高解像度（たとえば、正確に1000 DPI）で印刷された1行のテキストがあるとします。 この線は、紙の上で与えられた距離の87％を取ります（12.7 cmと仮定）。 ここで、12.7 cmが正確に500ピクセルに対応するように、100 DPIなどの低解像度の比例画像を取得する必要があります。 Windowsで500ピクセルの正確に87％を占めるテキストを表示する方法はありますか？ いや！ これは、以下のスクリーンショットから明らかです。 それらはWindows XPから削除されました。「画面のプロパティ->オプション->詳細->一般->スケール（インチあたりのドット数）->特別な設定...」。









彼らは（ Microsoft。およそTransl。 ）お金のためにエンジニアの名誉を犠牲にしました。それは技術的な進歩の欠如につながりました（ モニターの解像度を上げることで、およそTransl。 ）何年もの間。 彼らは過度に攻撃的なヒントを使用します。これは、キャラクターの形を歪めるだけでなく、行全体に大きな誤差（ 水平座標、約Transl。 ）を蓄積します。 その結果、フォントは自由にスケーラブルとは見なされず、スケーラブルに見えるだけですが、実際にはそうではありません。 この事実は、コンピューターモニター業界に影響を与えています。 600 DPIの解像度のモニターでWindows XPを想像できますか？ たとえば、8000x6000ピクセルですか？ できません。ビットマップアイコンだけでなく、主にテキストのスケーリングがひどいためです。 画面のプロパティで解像度を変更すると、プログラムの一部のダイアログボックスが必然的に正しく表示されなくなります。 したがって、高解像度モニターを製造する動機は何ですか？



ソフトウェア設計者は異なるフォントサイズを考慮する必要があると主張するかもしれません。 1つの小さな詳細がなければ、私はあなたに同意します。 100パーセント正しいダイアログボックスを作成するのは非常に面倒です。 Windows Vistaでは、無料のスケーリングははるかに優れた方法で実装されていますが、状況は既に存在し、改善するまでに長い時間がかかります。 つまり、ダイアログを自由に拡大縮小することはできません。



しばらく前に、Johnson＆Johnson（hello Dimitris Agrafiotisと他の同僚）で働いていましたが、.Net WinFormsプラットフォーム用の複雑なダイアログボックスを設計する必要がありました。 デフォルトでは、「Tahoma、10pt」のようなものが静的または編集可能なテキストに使用されました。 しかし、解像度を変更した後、テキストが割り当てられたスペースに規則的に収まらず、フォームを使用することは完全に不可能であったため、テキストの各行の最後に追加の空きスペースがあることを常に心配しなければなりませんでした。 そのため、比例スケーリングが心配な場合は、フォームをひどい方法でフォーマットする必要があり、大量の空き領域を「確保」しておく必要があります。 別の方法は、テキストサイズをピクセルに厳密にバインドすることです。 つまり、「Tahoma 14px」のようなものを使用します（ ptではなくpxに注意してください 。 それは多くのことを意味します。 これは、ソフトウェアを高解像度で使用できないことを意味します。 Windows Vistaがテキストスケーリングをどれだけサポートしているかは関係ありません。とにかく、既に問題が発生しています。 固定解像度に依存する膨大な量のソフトウェアが存在するため、モニターメーカーが高解像度画面を開発できなくなります。 動機はありません！ 私や他の多くのソフトウェア開発者やデザイナーを非難すべきではありません。 グラフィック要素のテキストの予測できないクロールにつながる、残忍なヒントについてマイクロソフトを非難します。



はい、WPFを搭載したWindows Vistaでは、すべてが自由にスケーラブルになります。 これは朗報です。 悪いニュースは、とにかく高解像度を使用できないことです。 これらの問題については、Long TsengとJim Matthewsが詳しく説明しています。

Long Zheng、Windows Vista DPIスケーリング：私のVistaはVistaよりも大きい。

www.istartedsomething.com/20061211/vista-dpi-scaling

Jim Mathies、XPスタイルDPIスケーリング。

www.mathies.com/weblog/?p=908

MicrosoftとAdobe：サブピクセルの配置とカーニング

WYSIWYGの原則に基づいて構築されたMicrosoft Wordでは、任意の解像度で正しいレイアウトを維持することが重要です。 つまり、マークアップは自由にスケーラブルでなければならず、本当にスケーラブルです。 しかし、少し調べてみましょう。 以下のテキストは、Office 2003のMicrosoft Wordでどのように表示されるかを示しています。このテキストを読む意味はありません。ただ見てください。







そして、Adobe Acrobat Readerでの表示と比較してください。







スライドショーをサポートするプログラムで両方の画像をダウンロードし、それらを切り替えると、違いをよりよく感じることができます（私は素敵で無料のIrfanViewを使用しています）。 Adobe Acrobatのテキストはより均一に見え、さらに、プリンターで表示されるものに非常に近いものです。 MS Wordのテキストはより鮮明に見えますが、全体的に見た目はいです。 なんで？ カーニング曲線のため。 低解像度でカーニングを完全に拒否しているように見えます（96 DPIは非常に小さいです）。 グリフをピクセルにスナップすると、最終的にはランダムに散らばったスペースがひどく見えます。 テキストの見栄えを良くする唯一の方法があります-水平サブピクセル配置を使用します。 これは、 コテルニコフの定理 （英国文学-ナイキスト-シャノンの定理または参照定理）に密接に関連する物理法則であり、次のように述べています。

アナログ信号のスペクトルが限られている場合、スペクトルの最大周波数の2倍を厳密に超える周波数で取得された離散サンプルから一意かつ無損失に再構築できます。

この場合、信号のスペクトルとは、サンプリング周波数を意味します。 実際には、これは、間隔がピクセルの倍数である限り、明確かつ等間隔で垂直線のセットを同時に正しく表示できないことを意味します。 線間の距離がジャンプするか、一部の線がぼやけて見えます。 他の選択肢、期間はありません。



Pierre Arnaudはこれをさらにわかりやすく実証しました。

「i」文字のグリフを出力する必要があるとします。グリフの幅は正確に2.4ピクセルです。 ヒントを使用すると、ほとんどの場合、出力で2ピクセル幅の画像が表示されます。 4ピクセルのスペースがあるとします。

ここで、「iiiiiiiiii」（グリフ「i」を10回）出力する必要があると想像してください。 これにより、画面上で20ピクセルを占める単語が得られますが、活版印刷の位置は24ピクセルシフトする必要があります。 後続のスペースに4ピクセルを追加し、サイズを事実上2倍にする必要があります。 画面上ではかなり奇妙に見えます。 グリフ「i」が実際に2.6ピクセルかかる場合、さらに悪いことになり、ヒンターはそれを3ピクセルに引き伸ばすことにします。 この場合、画面上の30ピクセルを占有しますが、活版印刷の位置は26ピクセルシフトしているはずです。 この場合、-4ピクセルのエラーが発生し、このエラーを補正すると後続のスペースが完全に消費されます。



別の試みは、文字体裁位置を丸めることによってグリフ「i」を配置することです。 このアプローチを適用した結果、x軸に沿って次の座標が得られます（グリフの幅が2.4ピクセルの場合）。

 x = 0 ----> 0エラー= 0幅= 2
 x = 2.4-> 2エラー= -0.4幅= 3
 x = 4.8-> 5エラー= +0.2幅= 2
 x = 7.2-> 7エラー= -0.2幅= 3
 x = 9.6-> 10エラー= +0.4幅= 2

結果はひどいものになります。

 。*。* .. *。* .. *
 ............
 。*。* .. *。* .. *
 。*。* .. *。* .. *
 。*。* .. *。* .. *
 。*。* .. *。* .. *

あなたはアイデアを得る...グリフ「i」間の間隔は可変になります。

はい、そうです。 これはまさにMicrosoft Wordで起こることです。







したがって、Microsoftはサブピクセルの配置を許可しませんが、Adobeは許可します。 これは、異なる位置にある同じグリフが画面上に異なる実際の表示を与える可能性があることを意味します。 これは、上記の例で赤い長方形でマークされた「機関」という言葉にはっきりと見られます。











Adobeのグリフ「i」、「n」、「s」、「t」を見てください。 異なる位置に少なくとも2つの異なるバージョンのディスプレイがあります。 そのため、Adobeのテキストはより均一に見えますが、同時にぼやけています。



これで、ワードパッドで同じ「institutions」という単語を入力すると、結果が異なります（さらに見た目が良くなります）。 では、なぜMS Wordでこんなに見栄えが悪いのでしょうか？ 位置決めの視覚的な不正確さのみが原因です。 ワードパッドで明らかに使用されているTextOut（）関数はこれを気にしませんが、MS Wordは強制されます（ スケーリング時に正しいレイアウトを維持するために、およそTransl。 ）。 100％確信はありませんが、MS Word開発者は、形のないグリフを使用して高解像度でグリフの変位を計算していると推測できます。 文書化されたWin32 APIを使用してこれを行う方法は1つしかありません。非常に大幅に増加したアフィン行列を使用してGetGlyphOutline（）を呼び出し、結果のグリフが1024x1024の長方形に収まるようにします。 この手法を直接使用すると、TextOut（）とまったく同じ結果が得られます。 見た目は良いのですが、テキストの行全体で知覚可能なエラーが蓄積されます（1単語だけで1文字のサイズを超える！）。



ダイアログボックスの場合、テキストの正確な幅を保持しないことが許容されると判断したようです。 なんで？ そうでなければ、署名、メニュー、ダイアログボックスなどはそれほど魅力的に見えないからです。 ランダムに散らばるカーニングにも同じ問題があり、明らかにソフトウェアの販売に悪影響を及ぼします。 したがって、ダイアログボックスの見やすいテキストはビジネスを促進しますが、テキストの幅にかなりの不正確さを蓄積するため、ダイアログボックスのサイズを変更することができなくなり、これによりメーカーは96 DPIのモニターを製造することを余儀なくされます-その結果、悪循環が生じます最終的に大きな冒とくになりました。



純粋にエンジニアリングの観点から見ると、テキストの明瞭さと機能性の間には合理的な妥協が必要です。 問題は、機能的な部分を完全に無視しつつ、マイクロソフトが魅力的なデザインに焦点を合わせていることです。 パラドックス：300 DPIではヒントはまったく必要ありません。さらに、テキストは自由にスケーラブルになります（600 DPI以上ではアンチエイリアスも必要ありません）が、300 DPIではソフトウェアを使用できません。せいぜい100 DPIの評価！ 魅力的な外観のために全世界が支払う価格を次に示します。 この価格は高すぎます。信じられないほど高いです。



それにもかかわらず、5年前（5 !!）でも、自由にスケーラブルなフォームとダイアログボックスを持つことは技術的に可能でした。 必要なのは、Mac OS Xほどではなく、非常にわずかな、ある程度のぼかしを許可することでした。むしろ、Adobe製品のように。 Windowsユーザーは、ぼやけた出力のSafariを好みません。 Windowsで使用されている以外のラスター化方法を盲目的に拒否することを除いて、私はそれらに部分的に同意します。 これはただの無謀な狂信です。 「解像度については気にせず、技術的な進歩を止める必要があったとしても、永遠に96 DPIのコストがかかったとしても、Windowsが以前のように見えるようにします」と言うのと同じです。 そのような見解は合理的であると考えることができますか？



Appleのラスタライゼーションにも満足していないので、Appleを支持して動揺することはありません。 私の意見では、それは本当にぼやけすぎに見えます。 彼らは、水平方向のストロークをぼかす自動ヒンティングアルゴリズムのようなものを使用しているように見えますが、実際には利点はありません。 実際、特にサンセリフフォントでは、意図的に鮮明なテキストを0.2..0.5ピクセルシフトしたかのように、ヒントも曲がっているように見えます。 そのため、WindowsユーザーはSafariをあまり好きではありません。 しかし同時に、彼らの多くはAdobe Acrobat Readerを喜んで使用し、満足しています。 それは、その中のテキストが受け入れられるように見えるためです（完璧ではありませんが、Windowsファンには受け入れられます）。 ただし、それは自由にスケーラブルなままです！ 単にドキュメントを読み込んで、スムーズにズームインおよびズームアウトしてみてください。 カーニング中も、テキストのマークアップは正しいままです。 だから、私はアドビの最高のレンダリング方法を最高と呼ぶでしょう。なぜなら、彼らの妥協は最適に非常に近いように見えるからです。

ClearTypeを使用したサブピクセルの配置：可能ですか？

Jeff Atwood [5]は、ピクセルグリッドへの厳密なバインドを支持して明確に述べています 。 私は自分の意見を持っています。 私はピクセルグリッドを考慮することに同意しますが、Y軸に沿っている場合のみです。Xでは、サブピクセルの配置を使用することが望ましいです。 同時に、私たちは過酷さを犠牲にします（しかしごくわずかですが）が、完全な自由を獲得します。



皮肉なことに、Microsoftは既にグリフのヒントにサブピクセルの配置を持っています。 おもしろいことに、これはJeffが使用しているフォントでJeffのページにはっきりと表示されています。







注意深く見てください。赤で強調表示されている「common」という単語と「m」という文字。







3つの縦の「m」ダッシュは異なります。 それにもかかわらず、元のテキストでは、彼らは非常にはっきりと魅力的に見えます。 これはどういう意味ですか？ たくさん。 これは、ClearTypeを使用すると、1/3ピクセルの精度で位置決めを使用できることを意味します。 それでは、なぜグリフをピクセルに添付するのですか？！ わかりません。 カーニングとクリアテキストを同時に正確に表示するには、1/3ピクセルの精度で十分です。 さて、私があなたを納得させていないなら、私は詳細にデモンストレーションします。 Microsoft Wordから1行のテキストのスクリーンショットを撮りました。 彼はこのように見えた：







次に、簡単なソフトウェア操作を使用して、色を各色に3つの値を許可するビットマップに変換しました。







次に、RGBカラーモデルでこのマップのアルファブレンディングを行い、各カラーチャネルを個別のグレーピクセルとして認識しました。 これを1グレーピクセルのオフセットで12回行い、RGBで1/3ピクセルのオフセットを得ました。 何が起こったのか見てください：







しかし、これはサブピクセルの位置決めです！ これは簡単に確認できます。12行にわたって4つの余分なピクセルが蓄積されていますが、文字の鮮明度には影響していません。 まあ、ラインはわずかに異なりますが、これに気付くにはそれらを非常によく見る必要があります（私は1つのビジョンを持っていることに注意し、眼鏡をかけません）。 私を信じて、これは正確なサブピクセル配置の自由のための非常に低価格です！ それで動作します。 かなり可能です。 サブピクセルポジショニングを使用してみませんか、マイクロソフト様、答えてください！ 答えはありません。





ところで、Windows Vistaにはサブピクセルの配置がありますか？ そうではないようです。 いずれにせよ、同じグリフが異なる位置の異なるピクセルセットにラスタライズされる単一の例を見つけることができませんでした。 ご覧のとおり、デフォルトのフォントサイズはわずかに増加しましたが（96 DPIの場合）、文字間隔が大きくなり、不正確な配置が目立たなくなりました。 これは良いことですが、もっときちんとした形のキャラクターはどうですか？ 認めざるを得ない。デジタルタイポグラフィの状況は、Vista以来あまり改善されていない。 そして、近い将来に変化することはほとんど期待できません。



もう1つの大きな質問は、Microsoft ClearType Font Collectionのタイトルです。 なぜ彼らは彼女のClearTypeフォントコレクションを呼び出すのですか？ この技術は特定のフォントと密接に結びついていますか？ そして、再び、この技術は非常に狭く専門化されたローカルソリューションの印象を与えるため、絶対にどのフォントにも適用できません。 以下では、FreeType autohinterツールを使用して、正直で普遍的な、フォントに依存しないラスタライズ方法を取得する方法を示します。 必要なのは、ベクトルグリフカーブだけです。 これ以上。

FontFocusがピクセル調整を実行する方法

ジェフは、とりわけ、FontFocus [4]のドキュメントを参照しています 。 すべての敬意を払って、私は彼女に反対しなければなりません。





垂直方向のヒントを無視しながら、ピクセルストロークを揃えます。 ご覧のとおり、文字「T」、「W」、「C」、「g」は非常にぼやけています。 さらに、「W」は他の部分よりも重く見えます。



私の意見では、これはかなりずさんに見えます。 これはTimes New Romanであると理解されています。 のように聞こえますか？ いいえ、プリミティブビットマップフォントのようなものです。 だからポイントは何ですか？ フォントを一度ラスターフォントとして保存し、低解像度で使用する方が簡単ではありませんか？標識の形状を歪める余裕がある場合、平滑化のポイントは何ですか？さらに、ソフトナプキンにインクで書かれたように、テキストには「スポット」があるようです。ストロークのほとんどは正しいですが、一部の場所では塗りつぶされています。いずれの場合も、問題は同じです。正しいレイアウトを拒否するか、カーニング曲線を取得します。



ここで、再びSafariについて言及したいと思います。私は完全に言うことはできませんが、Mac OSはサブピクセルカーニングも使用していないようです。これは最終的に、Microsoftのアプローチを批判して、上で書いた問題につながります。 Safariの方法は、文字の正しい位置を維持しながら正しいマークアップを取得することにはるかに近いですが、文字がピクセルにしっかりと付加されているように見えます。それで彼らの方針は何ですか？ラスタライズを具体的に使用するには、（低解像度-約Transl。で）非常にぼやけたテキストを与えますが、それは人々がより高い解像度のスクリーンを購入するためだけですか？不正なゲーム！



以下に、テキストの快適で正しい表示を実現する方法と、最も興味深いことに、非常に簡単な操作の結果を示します。私が使用しているFreeTypeライブラリのWin32 APIから[10]とのGetGlyphOutline（）関数を。言い換えれば、そのようなラスタ化スキームは、WindowsとLinuxの両方で、そしてもちろん、Mac OSでは可能です。FreeTypeもうまくコンパイルされます。さらに、FreeType autohinterは、私が行った方法で使用した場合、非常に正しく機能することがわかりました（通常の条件下では、その結果は受け入れられるとは言えません）。しかし、最初に、Linuxの世界の状況についてお話します。



続行するには...