X 論理フォント記述と HiDPI

X 論理フォント記述と HiDPI

質問:X-serverは固定解像度でフォントを提供します。100dpi、現在のWindowsシステムの解像度()の代わりにxdpyinfo | grep -F resolution

少し理論。 Xサーバー自体または別のサーバーからネットワーク(TCPまたはUNIXソケットを介して)を介してXクライアントに送信されるいくつかの従来のサーバー側のフォントがあります。XFontサーバー(単一または複数)。一般的なクライアント側フォント(Xft、GTK 2+、Qt 2+)とは異なり、「サーバー」バックエンド(またはCoreXフォントバックエンド)はアンチエイリアシングをサポートしませんが、ネットワークの透明性をサポートします(つまり、アルファチャンネルのないビットマップがネットワークを介して送信されます)。アプリケーションレベルでは、サーバー側のフォントは次のように指定されません。XftFontStruct(最も一般的におなじみのものに翻訳されていますDejaVu Sans Mono:size=12:antialias=trueXLFD。ローカルシステムでは、同じフォントファイルを両方のフォントバックエンドに同時に登録でき、最新のGTKおよびQtベースのアプリケーションだけでなく、従来のアプリケーション(Xt、Athena、Motif、GTK 1.2)でも使用できます。 、Qt 1.x)。

歴史的には、ラスターサーバー側のフォント(*.pcf)があり、ラスターには独自の解像度がありました(Windowsシステムの解像度と必ずしも同じではありません)。したがって、XLFDには、RESOLUTION_XなどのフィールドがありますRESOLUTION_Y。ラスターフォントが画面にレンダリングされたときに見苦しくなく、要求されたラスター化された文字サイズ()を維持するには、ラスター解像度が画面解像度にPIXEL_SIZE近い必要があるため、ラスターフォントは通常デフォルトの解像度で提供されます。75dpiそして100dpi(これが私たちがまだand etcディレクトリを持っている理由です/usr/share/fonts/X11/75dpi/usr/share/fonts/X11/100dpi。したがって、次の行は同じ12ptフォントを表します。

-bitstream-charter-bold-r-normal--12-120-75-75-p-75-iso8859-1
-bitstream-charter-bold-r-normal--17-120-100-100-p-107-iso8859-1

ラスター化されたグリフサイズは次のとおりです。

  • 12ピクセル存在する75dpi
  • 17ピクセル存在する100dpi、それぞれ。

ただし、ラスターフォントに加えて、ベクトルまたはアウトラインフォント(TrueType開いているアドビタイプ1)は任意の要素でサイズを変更でき、画面にレンダリングしてもまだ見えます。いくつかのXサーバーの実装(特に、新しい太陽)もサポートアドビタイプ3Turing-complete を使用してグリフを記述する形式PS言語。

もちろん、ラスター解像度の概念はベクトルフォントには適用されないため、フィールドに0(0)またはアスタリスク()を要求することが*できます。理論的には、私のXサーバーは私が要求したフォントを正確に提供する必要があります。これは直接RESOLUTION_XRESOLUTION_YArch Linux Wiki上記の記事へのリンク:

拡張可能なフォントは、サイズを変更できるように設計されています。拡張可能なフォント名(以下の例を参照)は、ピクセルおよびポイントサイズフィールド、2つの解像度フィールド、および平均幅フィールドにゼロを持ちます。

...

特定のサイズの拡張可能フォントを指定するには、POINT_SIZEこのフィールドに値を指定するだけで、他のサイズ関連の値はゼロのままにできます。値POINT_SIZEは1/10ポイント単位であるため、入力した値は目的のポイントサイズに10を掛けた値でなければなりません。

したがって、次の2つのクエリのいずれかを返す必要があります。12時 Courier Newウィンドウシステム解像度のフォント:


-monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
-monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1

または私はそう思った。。問題は96〜115dpiモニターで162dpi4kモニターで慎重に選択されたベクトルフォントが突然小さすぎるのを発見しました。

RESOLUTION_XRESOLUTION_Yフィールドを明示的に設定しない限り162(適切な精神を持っている人は誰もそうしません。Xresourcesモニターを変更するたびに数十行を書き直す必要があります。)その後、Xサーバーはデフォルトでフォントを次のようにレンダリングします。100dpi変える162。間の違い番号17そして27ピクセル(倍数1.62 = 162 / 100)が非常に目立ちます。これは現代的な例ですDebian 10箱:

Debian 10, Courier New 12pt, 162dpi

私はこの回帰が人々がX11から無駄なサブシステムを徐々に取り除いた結果だと思います。ディーン・ウッディ、2002年にリリースされた2.2カーネルでも同様の内容が見られます。

Debian 3, Courier New 12pt, 162dpi

唯一の違いはディーン・ウッディ明らかに、ネットワークを介してビットマップを送信する前にサーバー側でヒントを適用すると、フォントは「よりきれいな」方法でレンダリングされます。

だからこれは返品ではありません。この問題は持続し、すべてのベクトルフォントタイプに同じ影響を与えます(TrueType開いているタイプ1)。

今質問は。個々のリソースごとにユーザー設定にWindowsシステムの解像度をハードコーディングせずに、著者が推奨するよりも簡単にこの問題を解決する方法はありますか?システム間のXリソース共有記事?

libfreetypeXサーバー自体のグローバル構成やこれが依存するライブラリ(、)を変更すると、問題を解決できますかlibxfont

関連情報