| Java Platform, Standard Edition国際化ガイド リリース9 E90928-01 |
|
 前 |
Javaプラットフォームでは、すべての実装でサポートが求められる5つの論理フォント名(Serif、SansSerif、Monospaced、Dialog、DialogInput)が定義されています。論理フォント名は、実装に依存した方法で、物理フォントにマッピングされます。
Oracle JDKが論理フォント名と物理フォントをマップするには、font configurationファイルを使用します。ホスト・オペレーティング・システムのバージョンに応じて異なるマッピングをサポートする複数のファイルが存在する場合があります。ファイルは、JDKインストールで配布されます。ユーザーはフォント構成ファイルを変更したり新規に作成したりすることで、特定のシステム設定に応じてマッピングを調整できますが、これらのファイルはconf/fontsに配置する必要があり、次に説明する実装上の注意事項を考慮します。
フォント構成ファイルには2つの形式があります。プロパティ形式とバイナリ形式です。プロパティ形式については、このドキュメントで詳しく説明します。この形式は、ユーザー定義の構成のために使用できます。バイナリ形式については、ドキュメントが用意されておらず、JDKの事前定義済の構成に対してのみ使用されます。参照用に、それらの構成に対応するプロパティ形式のファイルが、.properties.srcという拡張子のファイルとして用意されています。
フォント構成ファイルは実装に依存しています。Javaプラットフォームのすべての実装でこのファイルが使用されるわけではありません。また、その内容と形式は実行環境やリリースの違いによって異なります。macOS実装はフォント構成ファイルを使用しません。これは、マッピングがソース内でハードコードされていて、変更できないためです。
Windowsの場合、フォント構成ファイルが必要です。
macOSの場合、フォント構成ファイルはサポートされていません。
LinuxおよびSolarisの場合: Oracle JDKでは、Linuxプラットフォームでカスタム・フォント構成ファイルの提供がサポートされなくなります。これは、配布やバージョン間で最新に保つことが困難なためです。システム上でフォントを制御する配布では、引き続き、このカスタム・ファイルを提供できます。JREでは、配布に正確に一致するカスタム・ファイルを検出した場合、これを使用します。完全一致するものが見つからない場合、JREでは実行時にファイルを動的に作成します。生成したこれらのファイルは、実装で決定された場所に配置されます。これらは内部的な実装とみなす必要があります。つまり、これらはユーザーが編集できるものではなく、この仕様で説明されている構文に従っていません。
JDKでは、提供するすべてのファイルを$JDKHOME/libに配置します。この場所は変更しないでください。かわりに、構成ファイルの更新またはカスタム・バージョンは$JDKHOME/conf/fontsに配置されます。
フォント構成ファイルをサポートしているプラットフォームでは、ランタイムは$JDKHOME/conf/fontsを最初に検索します。つまり、ユーザーによって提供されたファイルが一致すると、これが優先されます。
ホスト・オペレーティング・システム用のフォント構成ファイルは、次のように特定されます。
java.homeシステム・プロパティで指定される。"RedHat"、"SuSE"など。ランタイムでは、次のファイルのうち、最初に見つかったものが使用されます。
JavaHome/lib/fontconfig.OS.Version.propertiesJavaHome/lib/fontconfig.OS.Version.bfcJavaHome/lib/fontconfig.OS.propertiesJavaHome/lib/fontconfig.OS.bfcJavaHome/lib/fontconfig.Version.propertiesJavaHome/lib/fontconfig.Version.bfcJavaHome/lib/fontconfig.propertiesJavaHome/lib/fontconfig.bfc
.propertiesという拡張子のファイルは、Propertiesクラスで指定されるプロパティ・ファイルとみなされ、そのクラスによってロードされます。その拡張子のないファイルは、バイナリ形式と見なされます。
フォント構成ファイル全体で、さまざまな名前が使用されます。
serif、sansserif、monospaced、dialog、およびdialoginputのいずれか。フォント構成ファイルでは、これらの名前はすべて小文字で記述される。plain、bold、italic、およびbolditalicのいずれか。この場合も、すべて小文字で表される。"Courier New"や"\uad74\ub9bc"のようなフォント・フェース名。"-monotype-times new roman-regular-r---*-%d-*-*-p-*-iso8859-1"のようなxlfd名。"%d"はフォント・サイズを示し、実際のフォント・サイズが実行時に挿入される。java.nio.charset.Charset.defaultCharset().name()により返される名前。すべてのプラットフォームに適用可能なプロパティを使用すると、フォント構成の形式のバージョン、コンポーネント・フォントのマッピング、検索順序、除外範囲、プロポーショナル・フォント、フォント・ファイル名および追加のフォント・パスを指定できます。
バージョン・プロパティは、フォント構成の形式のバージョンを識別するものです。このドキュメントで規定しているのは、バージョン1です。
完全なプロパティの形式は次のとおりです。
version=1
コンポーネント・フォントのマッピングのプロパティでは、特定の文字サブセットの文字を、特定のスタイルの特定の論理フォントでレンダリングするときに使用する物理フォントを指定します。
キーの形式は次のとおりです。
allfonts.CharacterSubsetName LogicalFontName.StyleName.CharacterSubsetName
第1の形式は、論理フォントやスタイルとは無関係に、同じフォントを文字サブセットに使用する場合に利用します。この場合、フォント・レンダリング・エンジンは、アルゴリズム的にスタイルをフォントに適用します。第2の形式は、異なる論理フォントおよびスタイルごとに、別々の物理フォントを文字サブセットに使用する場合に利用します。この形式では、論理フォントとスタイルの組合せそれぞれについてプロパティを指定する必要があるため、1つの文字サブセットに対して20のプロパティを指定することになります。ある文字サブセットに対して第1の形式のプロパティが指定されている場合、同じ文字サブセットに対して第2の形式のプロパティが指定されていても無視されます。
値は、「フォント構成ファイル内で使用される名前」で説明されているように、プラットフォーム・フォント名です。
各種フォントによってサポートされる文字サブセットは重複することが多いので、文字をレンダリングする際に使用するフォントの順序を定義するために、別の検索順序プロパティを使用します。
Javaランタイムでは、5つの論理フォントの検索順序を判別するためにsequenceプロパティが使用されます。ただし、フォント構成ファイルでは、エンコーディング、言語、国の特定の組合せに対してプロパティを指定できます。その場合、ランタイムでは、各論理フォントのsequenceプロパティを参照して順序が判別されます。
キーの形式は次のとおりです。
sequence.allfonts.Encoding.Language.Country sequence.LogicalFontName.Encoding.Language.Country sequence.allfonts.Encoding.Language sequence.LogicalFontName.Encoding.Language sequence.allfonts.Encoding sequence.LogicalFontName.Encoding sequence.allfonts sequence.LogicalFontName
allfontsの形式は、5つの論理フォントすべてに対して順序を使用する場合に利用します。論理フォント名を指定する形式は、異なる論理フォントに対し異なる順序を使用する場合に利用します。
各論理フォントについて、Javaランタイムでは、上記のキーのうち最初に登場するプロパティ値が使用されます。このプロパティにより、論理フォントの主検索順序が決まります。
このファイルでは、1つの代替検索順序を定義することもできます。代替sequenceプロパティのキーの形式は次のとおりです。
sequence.fallback
すべてのsequenceプロパティの値は、次の形式で指定します。
SearchSequenceValue: CharacterSubsetName CharacterSubsetName , SearchSequenceValue
主sequenceプロパティでは、必須フォントの文字サブセット名を指定します。AWTおよび2Dのフォント・レンダリングではどちらも、これらのフォントが使用されます。代替sequenceプロパティでは、オプション・フォントの文字サブセット名を指定します。これらのフォントはすべての論理フォントの代替として使用されますが、2Dのフォント・レンダリングの場合のみです。ランタイムでは、Lucida Sans Regularフォントが2Dレンダリング用の代替フォントとして自動的に追加されます(まだ指定されていない場合)。また、実行環境にlib/fonts/fallbackディレクトリが存在し、そのディレクトリに有効なTrueTypeフォントまたはType 1フォントが含まれている場合は、それらのフォントが2Dレンダリング用の代替フォントとして自動的に追加されます。Windowsでは、システムEUDC (End User Defined Characters)フォントがWindowsに登録されている場合、そのフォントも2Dレンダリング用の代替フォントとして自動的に追加されます。
sequenceプロパティにより、特定の文字をレンダリングするために、コンポーネント・フォントをどのような順序で使用するかが決まります。たとえば、次のようなプロパティを指定したとします。
sequence.monospaced=japanese,alphabetic sequence.fallback=korean monospaced.plain.alphabetic=Arial monospaced.plain.japanese=MSGothic monospaced.plain.korean=Gulim
ランタイムでは、まず、MSGothicフォントを使用して文字をレンダリングしようとします。そのフォントがその文字のグリフを提供していない場合は、Arialフォントを試します。2Dレンダリングでは、さらに、GulimフォントとLucida Sans Regularフォントのほか、ランタイムのlib/fonts/fallbackディレクトリにあるTrueTypeフォントまたはType 1フォントも試します。Windows上での2Dレンダリングでは、システムEUDCフォントがWindowsに登録されている場合、そのEUDCフォントも試します。
文字列を参照せずに論理フォントのフォント・メトリックスを計算する場合には、必須フォントのみが考慮に入れられます。たとえば、前述の例であれば、FontMetrics.getMaxDescentメソッドはMSGothicフォントとArialフォントに基づいて結果を返します。GulimフォントとLucida Sansフォントは考慮に入れられません。このため、ボタンなど、単純なユーザー・インタフェース要素(フォント・メトリックに基づいて要素のサイズが計算されることがある)は、その要素が通常は使用しないコンポーネント・フォントを含む拡張リストから影響を受けることはありません。一方、テキスト・コンポーネントでは、通常実際に表示するテキストに基づいてメトリックを計算するため、正しい結果が得られます。
5つの論理フォントについてランタイムが取得するsequenceプロパティは、同じ文字サブセットを列挙している必要がありますが、文字セット列挙する順序は異なっていてもかまいません。
除外範囲プロパティでは、特定の文字サブセットに対応するフォントによるレンダリングの対象から除外するUnicode文字の範囲を指定します。このプロパティは、(パフォーマンス上の理由などで)多数の文字をサポートしているフォントを早い検索順位に置く必要があるが、そのフォントがサポートしている文字の一部を別のフォントで描画する必要がある場合に使用します。このプロパティはオプションで、指定できるのは文字サブセットあたり1つまでです。
キーの形式は次のとおりです。
exclusion.CharacterSubsetName
値の形式は次のとおりです。
ExclusionRangeValue: Range Range , ExclusionRangeValue Range: Char - Char Char: HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit
Charは、Unicode文字を16進数として表現したものです。
プロポーショナル・フォント・プロパティでは、同じフォントのプロポーショナル版と非プロポーショナル版の関係を記述します。このプロパティは、GraphicsEnvironment.preferProportionalFontsメソッドで指定する設定を実装するために使用されます。
キーの形式は次のとおりです。
proportional.PlatformFontName
プラットフォーム・フォント名に含まれている空白文字は、アンダースコア(_)に置き換える必要があります。
値の形式は次のとおりです。
PlatformFontName
値の指定では、空白文字は元のまま残します。
各プロパティは、値として指定したフォントがキーに指定したフォントのプロポーショナル版であることと、キーに指定したフォントが値として指定したフォントの非プロポーショナル版であることを示します。
フォント・ファイル名のプロパティは、フォント構成ファイルで使用される物理フォントを格納しているファイルの名前を指定します。Windowsでは、すべての物理フォントについてファイル名の指定が必須です。SolarisおよびLinuxでは、すべての物理フォントについてファイル名の指定が推奨されています。
キーの形式は次のとおりです。
filename.PlatformFontName
プラットフォーム・フォント名に含まれている空白文字は、アンダースコア(_)に置き換える必要があります。
値は、フォントを格納しているファイルのファイル名です。Windowsでは、単純なファイル名を指定します。そのため、実行環境では、まず自身のlib/fontsディレクトリから各ファイルが検索され、次にWindowsのフォント・ディレクトリから検索されます。SolarisおよびLinuxでは、絶対パス名、実行環境のlib/fontsディレクトリを表す"$JRE_LIB_FONTS"で始まるパス名、またはxlfd名を使用します。
Javaランタイムでは、ランタイムのlib/fontsディレクトリや、Windowsのフォント・フォルダなど、フォント・ファイルが格納されているいくつかのディレクトリを自動的に判別できます。このフォント・パスに追加するため、追加のディレクトリを指定することができます。
キーの形式は次のとおりです。
appendedfontpath
値の形式は次のとおりです。
AppendedFontPathValue: Directory Directory PathSeparator AppendedFontPathValue
パス区切り文字は、プラットフォームに依存するjava.io.File.pathSeparatorの値です。
Windowsでは、プラットフォーム固有のプロパティはありません。ただし、検索順序の指定に使用する、特別な形式の文字サブセット名があります。「alphabetic」という文字サブセット名に、そのサブセットに関連付ける文字エンコーディングを示す接尾辞を付けることができます。
alphabetic alphabetic/default alphabetic/1252
この情報は、AWTでのみ使用され、2Dでは使用されません。/defaultという接尾辞を指定すると、この文字サブセットに対するコンポーネント・フォントの使用が、デフォルト・エンコーディングの文字セットに限定されます。また、/1252という接尾辞を指定すると、Windows-1252文字セットに限定されます。コンポーネント・フォントのマッピングと除外範囲にアクセスするには、文字エンコーディングの接尾辞を省略します。これ以外のすべての文字サブセットについて、AWTの文字エンコーディングは、Javaランタイムによって内部的に判別されます。
SolarisおよびLinuxに固有の唯一のプロパティはAWTフォント・パスであり、これはX11サーバー・フォント・パスに追加する必要のあるプラットフォーム・ディレクトリを指定します。
キーの形式は次のとおりです。
awtfontpath.CharacterSubsetName
値の形式は次のとおりです。
AWTFontPathValue: Directory Directory : AWTFontPathValue
指定するディレクトリは、有効なX11フォント・ディレクトリであることが必要です。Javaランタイムは、検索順序の参照で見つかる主検索順序に含まれるすべての文字サブセットのディレクトリが、確実にX11フォント・パスに組み込まれるようにします(「検索順序」を参照)。実装では、同じエンコーディング、言語、国が設定されている特定の環境について、すべての論理フォントが同じ一式の文字サブセットを使用することを前提としています。
