フォントのレンダリングは実際にはどのように機能しますか？

コンピューターでフォントがレンダリングされる方法については、基本的に何も知らないことに気づきました。

私が観察できることから、フォントのレンダリングは通常、システム全体で一貫した方法で行われています。たとえば、DEコントロールパネルで構成したサブピクセルフォントのヒンティング設定は、ウィンドウの境界線、ブラウザー、テキストエディターなどに表示されるテキストに影響を与えます。（私はいくつかのJavaアプリケーションが顕著な違いを示すことを観察する必要があるので、それらは異なるフォントレンダリングメカニズムを使用していると思います）。

上記から得られるのは、フォントのレンダリングを必要とするすべてのアプリケーションが、OS（またはDE）全体のライブラリを利用しているということです。

一方、ブラウザーは通常、レンダリングエンジンを介して独自のレンダリングを管理し、特定のフロールールに従って、テキストを含むさまざまなアイテムの配置を処理します。

これら2つの事実がどのように互換性があるのか​​はわかりません。ブラウザはOSに特定の位置にグリフを描画するように要求する必要があると思いますが、グリフがどのくらいのスペースを取るかを事前に知らずに、テキストのフローを管理するにはどうすればよいですか？グリフのサイズを決定するための個別の呼び出しはありますか？これにより、ブラウザーは、文字がOSによって後で入力される小さなボックスであるかのようにフローを管理できますか？（ただし、これはカーニングを処理しません）。または、OSはテキストフローを含むテキスト領域全体を描画する責任がありますか？OSはレンダリングされたグリフをビットマップとして返​​し、それをアプリケーションに残して画面に描画しますか？

一般に、アプリケーションは、OSまたはGUIツールキットが提供するライブラリを使用してフォントレンダリングを行うのが正しいです。

一般的なフォントエンジンでは、さまざまな操作モードを使用できます。単純なケースでは、アプリケーションは特定の位置にテキストの文字列を描画するように要求でき、エンジンがすべて（測定、配置、ピクセルをディスプレイに描画するなど）を処理します。

より細かい制御が必要なアプリケーション（ブラウザやワードプロセッサなど）の場合、エンジンは、アプリが特定のテキストを事前に測定するように要求できるインターフェイスを公開します。その後、アプリはこの知識を使用して、行に収まるテキストの量、改行の位置、段落がどのくらいのスペースを取るかなどを計算できます。アプリは、実際のレンダリングを実行するようにエンジンに要求できますピクセルの。

（エンジンが最大幅のパラメーターと、場合によってはいくつかのカーニング/パディングパラメーターを取り、それに収まるだけのテキストを自動的にレンダリングするという中間のシナリオが存在する可能性があります。）

最後に、フォントエンジンは、特定のサイズで事前にレンダリングされたグリフのビットマップを返すことにより、アプリがテキストの最終的なレンダリングを引き継ぐことを可能にし、アプリがそれを配置して最終的なディスプレイに合成できるようにします。あるいは、エンジンは、いくつかのベクトルツールキットでレンダリングするために生のグリフアウトラインデータを返すことさえ提案するかもしれません。