「Font Configuration」


The Java Platform defines five logical font names that every implementation
must support: Serif, SansSerif, Monospaced, Dialog, and DialogInput. These
logical font names are mapped to physical fonts in implementation dependent
Sun’s Java SE Runtime Environments use font configuration files to map logical
font names to physical fonts. There are several files to support different
mappings depending on the host operating system version. The files are located
in the lib directory within the JRE installation. Users can edit or create
their own font configuration files to adjust the mappings to their particular
system setup. Note however that this is a modification of the JRE, and Sun does
not support modified JREs.
Font configuration files come in two formats: A properties format and a binary
format. The properties format is described in detail in this document and can
be used for user-defined configurations. The binary format is undocumented and
used only for the JRE’s predefined configurations; the corresponding files in
properties format are available for reference as files with the
“.properties.src” extension.
Note that font configuration files are implementation dependent. Not all
implementations of the Java Platform use them, and the format and content vary
between different runtime environments as well as between releases. This
document describes the format used by version 6 of Sun’s Java SE Runtime
1. Loading_Font_Configuration_Files
2. Names_Used_in_Font_Configuration_Files
3. Properties_for_All_Platforms
4. Properties_for_Windows
5. Properties_for_Solaris_and_Linux

Loading Font Configuration Files


  • JavaHome – the JRE’s directory, as given by the “java.home” system property.
  • OS – a string identifying an operating system variant:
o For Windows, “98”, “2000”, “Me”, “XP”, “2003”.

o For Solaris, empty.

o For Linux, “Sun”, “RedHat”, “Turbo”, “SuSE”.
  • Version – a string identifying the operating system version.

这些信息可以使用java -XshowSettings:properties -version命令进行查看。

The runtime uses the first of the following files it finds:









Files with a “.properties” suffix are assumed to be properties files as
specified by the Properties class and are loaded through that class. Files
without this suffix are assumed to be in binary format.


/src/java.desktop/share/classes/sun/awt/FontConfiguration.java类文件中private File findFontConfigFile(String)方法。


Names Used in Font Configuration Files

Throughout the font configuration files, a number of different names are used:

  • LogicalFontName – one of the five logical font names: serif, sansserif,
monospaced, dialog, and dialoginput. In font configuration files, these

names are always in lowercase.
  • StyleName – one of the four standard font styles: plain, bold, italic,
and bolditalic. Again, these names are always in lowercase.
  • PlatformFontName – the name of a physical font, in a format typically
used on the platform:
o On Windows, a font face name, such as “Courier New” or
o On Solaris and Linux, an xlfd name, such as “-monotype-times new
roman-regular-r—*-%d-*-*-p-*-iso8859-1″. Note that “%d” is used

for the font size – the actual font size is filled in at runtime.
  • CharacterSubsetName – a name for a subset of the Unicode character set
which certain component fonts can render. For Windows, the following

names are predefined: alphabetic, arabic, chinese-ms936, chinese-gb18030,

chinese-ms950, chinese-hkscs, cyrillic-iso8859-5, cyrillic-cp1251,

cyrillic-koi8-r, devanagari, dingbats, greek, hebrew, japanese, korean,

latin, symbol, thai. For Solaris and Linux, the following names are

predefined: arabic, chinese-gb2312, chinese-gbk, chinese-gb18030-0,

chinese-gb18030-1, chinese-cns11643-1, chinese-cns11643-2, chinese-

cns11643-3, chinese-big5, chinese-hkscs, cyrillic, devanagari, dingbats,

greek, hebrew, japanese-x0201, japanese-x0208, japanese-x0212, korean,

korean-johab, latin-1, latin-2, latin-4, latin-5, latin-7, latin-9,

symbol,thai. A font configuration file may define additional names to

identify additional character subsets.
  • Encoding – the canonical name of the default encoding, as provided by
  • Language – the language of the initial default locale.
  • Country – the country of the initial default locale.


Properties for All Platforms

** Version Property **
The version property identifies the font configuration format version. This
document specifies version 1.
The complete property has the form:

* Component Font Mappings *
Component font mapping properties describe which physical font to use to render
characters from a given character subset with a given logical font in a given
The keys have the forms:



The first form is used if the same font is used for a character subset

independent of logical font and style (in this case, the font rendering engines

apply algorithmic styles to the font). The second form is used if different

physical fonts are used for a character subset for different logical fonts and

styles. In this case, properties must be specified for each combination of

logical font and style, so 20 properties for one character subset. If a

property of the first form is present for a character subset, then properties

of the second form for the same character subset are ignored.

The values are platform font names, as described above.

Since the character subsets supported by given fonts often overlap, separate

search sequence properties are used to define in which order to try the fonts

when rendering a character.

* Search Sequences *
The Java runtime uses sequence properties to determine search sequences for the
five logical fonts. However, a font configuration file may specify properties
that are specific to a combination of encoding, language, and country, and the
runtime will then use a lookup to determine the search sequence property for
each logical font.
The keys have the form:








The allfonts forms are used if the sequence is used for all five logical fonts.

The forms specifying logical font names are used if different sequences are

used for different logical fonts.

For each logical font, the Java runtime uses the property value with the first

of the above keys. This property determines the primary search sequence for the

logical font.

The file may also define a single fallback search sequence. The key for the

fallback search sequence property is:


The values of all search sequence properties have the form:



CharacterSubsetName , SearchSequenceValue

The primary search sequence properties specify character subset names for

required fonts, which are used for both AWT and 2D font rendering. The fallback

search sequence property gives character subset names for optional fonts, which

are used as fallbacks for all logical fonts, but only for 2D font rendering.

The runtime automatically adds the Lucida Sans Regular font as a fallback font

for 2D rendering if it’s not already specified. If the runtime environment has

a directory lib/fonts/fallback and this directory contains valid TrueType or

Type 1 fonts, the runtime automatically adds these fonts as fallback fonts for

2D rendering. On Windows, if there is a system EUDC (End User Defined

Characters) font registered with Windows, the runtime automatically adds this

font as well as a fallback font for 2D rendering.

The sequence properties determine in which sequence component fonts are tried

to render a given character. For example, given the following properties:






the runtime will first attempt to render a character with the MSGothic font. If

that font doesn’t provide a glyph for the character, it will attempt the Arial

font. For 2D rendering, it will also try the Gulim and the Lucida Sans Regular

font as well as any TrueType or Type 1 fonts in the runtime’s lib/fonts/

fallback directory. For 2D rendering on Windows, if there is a system EUDC font

registered with Windows, the runtime will finally try this EUDC font.

When calculating font metrics for a logical font without reference to a string,

only the required fonts are taken into consideration. For the example above,

the FontMetrics.getMaxDescent method would return results based on the MSGothic

and Arial fonts, but not the Gulim and Lucida Sans fonts. In this way, simple

user interface elements such as buttons, which sometimes calculate their size

based on font metrics, are not affected by an extended list of component fonts

which their labels usually don’t use. On the other hand, text components

typically calculate metrics based on the text they contain and thus will obtain

correct results.

The sequence properties that the runtime obtains for the five logical fonts

should list the same character subsets, but may list them in different order.

* Exclusion Ranges *
The exclusion range properties specify Unicode character ranges which should be
excluded from being rendered with the fonts corresponding to a given character
subset. This is used if a font with a large character repertoire needs to be
placed early in the search sequence (for example, for performance reasons), but
some characters that it supports should be drawn with a different font instead.
These properties are optional, so there’s at most one per character subset.
The keys have the form:


The values have the form:



Range , ExclusionRangeValue



Char – Char



HexDigit HexDigit HexDigit HexDigit

HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit

A Char is a Unicode character represented as a hexadecimal value.

* Proportional Fonts *
The proportional font properties describe the relationship between proportional
and non-proportional variants of otherwise equivalent fonts. These properties
are used to implement preferences specified by the
GraphicsEnvironment.preferProportionalFonts method.
The keys have the form:


Space characters in the platform font name must be replaced with underscore

characters (“_”).

The values have the form:


In values, space characters are left unmodified.

Each property indicates that the font named in the value is the proportional

equivalent of the font named in the key, and also that the font named in the

key is the non-proportional equivalent of the font named in the value.

* Font File Names *
Font file name properties provide the names of the files containing the
physical fonts used in the font configuration file. File names are required for
all physical fonts on Windows and recommended for all physical fonts on Solaris
and Linux.
The keys have the form:


Space characters in the platform font name must be replaced with underscore

characters (“_”).

The values are the file names of the files containing the fonts. On Windows,

simple file names are used; and the runtime environment looks for each file

first in its own lib/fonts directory, then in the Windows fonts directory. On

Solaris and Linux, absolute path names, path names starting with

“$JRE_LIB_FONTS” for the runtime environment’s own lib/fonts directory, or xlfd

names are used.

* Appended Font Path *
The Java runtime can automatically determine a number of directories that
contain font files, such as its own lib/fonts directory or the Windows fonts
folder. Additional directories can be specified to be appended to the font
The key has the form:


The value has the form:



Directory PathSeparator AppendedFontPathValue

The path separator is the platform dependent value of



Properties for Windows

There are no platform-specific properties for Windows. However, there is a
special form of the character subset name used in search sequences. The name
“alphabetic” can take a suffix indicating the character encoding associated
with the subset:



This information is only used for AWT, not for 2D. The “/default” suffix

restricts use of the component fonts for this character subset to the character

set of the default encoding; the “/1252” suffix to the Windows-1252 character

set. For accessing component font mappings and exclusion ranges, the character

encoding suffix is omitted. For all other character subsets, the AWT character

encoding is determined internally by the Java runtime.


Properties for Solaris and Linux

** Motif Component Font Mappings **
The AWT text components, which rely on Motif-based peers for text rendering,
cannot always use the same platform fonts as other AWT components and 2D. When
looking up component fonts for these components, additional keys are
recognized. The complete set of keys looked up in this case is:




* AWT X11 Font Path *
The AWT font path properties specify platform directories which should be added
to the X11 server font path. The keys have the form:
The values have the form:


Directory : AWTFontPathValue

The directories must be valid X11 font directories. The Java runtime ensures

that the directories for all character subsets of a primary search sequence

found by the search_sequence_lookup are part of the X11 font path. The

implementation assumes that all logical fonts use the same set of character

subsets for a given environment of encoding, language, and country.


Font Configuration Files: https://docs.oracle.com/javase/8/docs/technotes/guides/intl/fontconfig.html