質問: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=true
)XLFD。ローカルシステムでは、同じフォントファイルを両方のフォントバックエンドに同時に登録でき、最新の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_X
RESOLUTION_Y
Arch 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_X
とRESOLUTION_Y
フィールドを明示的に設定しない限り162(適切な精神を持っている人は誰もそうしません。Xresources
モニターを変更するたびに数十行を書き直す必要があります。)その後、Xサーバーはデフォルトでフォントを次のようにレンダリングします。100dpi変える162。間の違い番号17そして27ピクセル(倍数1.62 = 162 / 100
)が非常に目立ちます。これは現代的な例ですDebian 10箱:
私はこの回帰が人々がX11から無駄なサブシステムを徐々に取り除いた結果だと思います。ディーン・ウッディ、2002年にリリースされた2.2カーネルでも同様の内容が見られます。
唯一の違いはディーン・ウッディ明らかに、ネットワークを介してビットマップを送信する前にサーバー側でヒントを適用すると、フォントは「よりきれいな」方法でレンダリングされます。
だからこれは返品ではありません。この問題は持続し、すべてのベクトルフォントタイプに同じ影響を与えます(TrueType、開いている、タイプ1)。
今質問は。個々のリソースごとにユーザー設定にWindowsシステムの解像度をハードコーディングせずに、著者が推奨するよりも簡単にこの問題を解決する方法はありますか?システム間のXリソース共有記事?
libfreetype
Xサーバー自体のグローバル構成やこれが依存するライブラリ(、)を変更すると、問題を解決できますかlibxfont
?