标签：
字体是个非常平常的概念，以至于看到Java API文档对于字体的长篇大论的说明时，我突然感觉自己很无知。
以下是英文原文：
The Font class represents fonts, which are used to render text in a visible way. A font provides the information needed to map sequences of
characters to sequences of glyphs and to render sequences of glyphs on
Graphics and Component objects.
A character is a symbol that represents an item such as a letter, a digit, or punctuation in an abstract way. For example,
‘g‘, LATIN SMALL LETTER G, is a character.
A glyph is a shape used to render a character or a sequence of characters. In simple writing systems, such as Latin, typically one glyph represents one character. In general, however, characters and glyphs do not have one-to-one correspondence. For example, the character ‘á‘ LATIN SMALL LETTER A WITH ACUTE, can be represented by two glyphs: one for ‘a‘ and one for ‘′‘. On the other hand, the two-character string "fi" can be represented by a single glyph, an "fi" ligature. In complex writing systems, such as Arabic or the South and South-East Asian writing systems, the relationship between characters and glyphs can be more complicated and involve context-dependent selection of glyphs as well as glyph reordering. A font encapsulates the collection of glyphs needed to render a selected set of characters as well as the tables needed to map sequences of characters to corresponding sequences of glyphs.
The Java Platform distinguishes between two kinds of fonts: physical fonts and logical fonts.
Physical fonts are the actual font libraries containing glyph data and tables to map from character sequences to glyph sequences, using a font technology such as TrueType or PostScript Type 1. All implementations of the Java Platform must support
TrueType fonts; support for other font technologies is implementation dependent. Physical fonts may use names such as Helvetica, Palatino, HonMincho, or any number of other font names. Typically, each physical font supports only a limited set of writing systems,
for example, only Latin characters or only Japanese and Basic Latin. The set of available physical fonts varies between configurations. Applications that require specific fonts can bundle them and instantiate them using the
createFont method.
Logical fonts are the five font families defined by the Java platform which must be supported by any Java runtime environment: Serif, SansSerif, Monospaced, Dialog, and DialogInput. These logical fonts are not actual font libraries. Instead, the logical font names are mapped to physical fonts by the Java runtime environment. The mapping is implementation and usually locale dependent, so the look and the metrics provided by them vary. Typically, each logical font name maps to several physical fonts in order to cover a large range of characters.
Peered AWT components, such as Label and
TextField, can only use logical fonts.
For a discussion of the relative advantages and disadvantages of using physical or logical fonts, see the Internationalization FAQ document.
A Font can have many faces, such as heavy, medium, oblique, gothic and regular. All of these faces have similar typographic design.
There are three different names that you can get from a Font object. The
logical font name is simply the name that was used to construct the font. The
font face name, or just font name for short, is the name of a particular font face, like Helvetica Bold. The
family name is the name of the font family that determines the typographic design across several faces, like Helvetica.
The Font class represents an instance of a font face from a collection of font faces that are present in the system resources of the host system. As examples, Arial Bold and Courier Bold Italic are font faces. There can be several
Font objects associated with a font face, each differing in size, style, transform and font features.
The getAllFonts method of the
GraphicsEnvironment class returns an array of all font faces available in the system. These font faces are returned as
Font objects with a size of 1, identity transform and default font features. These base fonts can then be used to derive new
Font objects with varying sizes, styles, transforms and font features via the
deriveFont methods in this class.
Font supports most TextAttributes. This makes some operations, such as rendering underlined text, convenient since it is not necessary to explicitly construct a
TextLayout object. Attributes can be set on a Font by constructing or deriving it using a
Map of TextAttribute values.
The values of some TextAttributes are not serializable, and therefore attempting to serialize an instance of
Font that has such values will not serialize them. This means a Font deserialized from such a stream will not compare equal to the original Font that contained the non-serializable attributes. This should very rarely pose a problem since these
attributes are typically used only in special circumstances and are unlikely to be serialized.
FOREGROUND and BACKGROUND use Paint values. The subclass
Color is serializable, while GradientPaint and TexturePaint are not.CHAR_REPLACEMENT uses GraphicAttribute values. The subclasses
ShapeGraphicAttribute and ImageGraphicAttribute are not serializable.INPUT_METHOD_HIGHLIGHT uses InputMethodHighlight values, which are not serializable. See
java.awt.im.InputMethodHighlight.Clients who create custom subclasses of Paint and GraphicAttribute can make them serializable and avoid this problem. Clients who use input method highlights can convert these to the platform-specific attributes for that highlight
on the current platform and set them on the Font as a workaround.
The Map-based constructor and deriveFont APIs ignore the FONT attribute, and it is not retained by the Font; the static
getFont method should be used if the FONT attribute might be present. See
java.awt.font.TextAttribute.FONT for more information.
Several attributes will cause additional rendering overhead and potentially invoke layout. If a
Font has such attributes, the hasLayoutAttributes()
Note: Font rotations can cause text baselines to be rotated. In order to account for this (rare) possibility, font APIs are specified to return metrics and take parameters ‘in baseline-relative coordinates‘. This maps the ‘x‘ coordinate to the advance along the baseline, (positive x is forward along the baseline), and the ‘y‘ coordinate to a distance along the perpendicular to the baseline at ‘x‘ (positive y is 90 degrees clockwise from the baseline vector). APIs for which this is especially important are called out as having ‘baseline-relative coordinates.‘
为了理解这段说明，安装了很久不用的英文词典，也下载了中文版的API文档，以下为中文翻译：
Font 类表示字体，可以使用它以可见方式呈现文本。字体提供将字符 序列映射到字形 序列所需要的信息，以便在
Graphics 对象和 Component 对象上呈现字形序列。
字符 是表示项的符号（如字母、数字或具有抽象意义的标点）。例如，‘g‘（G 的拉丁小写字母）是一个字符。
字形 是用来呈现字符或字符序列的一种形状。在简单的书写系统（如拉丁文）中，通常一个字形就表示一个字符。但在一般情况下，字符和字形并没有一对一的对应关系。例如，字符 ‘á‘ A 的带重音符号的拉丁小写字母 可以由两个字形表示：一个是 ‘a‘，一个是 ‘′‘。另一方面，两字符的字符串 "fi" 可以由单个字形 "fi" 连字表示。在复杂的书写系统（如阿拉伯语或南亚和东南亚语言）中，字符与字形之间的关系可能更复杂，涉及到依赖于上下文的字形选择以及字形重排序。字体封装了呈现所选择的字符集所需的字形集，还封装了将字符序列映射到相应的字形序列所需的表。
Java Platform 可以区分两种字体：物理 字体和逻辑 字体。
物理 字体是实际的字体库，包含字形数据和表，这些数据和表使用字体技术（如 TrueType 或 PostScript Type 1）将字符序列映射到字形序列。Java Platform 的所有实现都支持 TrueType 字体；对其他字体技术的支持是与实现相关的。物理字体可以使用字体名称，如 Helvetica、Palatino、HonMincho 或任意数量的其他字体名称。通常，每种物理字体只支持有限的书写系统集合，例如，只支持拉丁文字符，或者只支持日文和基本拉丁文。可用的物理字体集合随配置的不同而有所不同。要求特定字体的应用程序可以使用
createFont 方法来捆绑这些字体，并对其进行实例化。
逻辑 字体是由必须受所有 Java 运行时环境支持的 Java 平台所定义的五种字体系列：Serif、SansSerif、Monospaced、Dialog 和 DialogInput。这些逻辑字体不是实际的字体库。此外，由 Java 运行时环境将逻辑字体名称映射到物理字体。映射关系与实现和通常语言环境相关，因此它们提供的外观和规格各不相同。通常，为了覆盖庞大的字符范围，每种逻辑字体名称都映射到几种物理字体。
同级的 AWT 组件（如 Label 和
TextField）只可以使用逻辑字体。
有关使用物理字体或逻辑字体的相对优势和劣势的讨论，请参阅 Internationalization FAQ 文档。
Font 可以有多个外观，如 heavy、medium、oblique、gothic 和 regular。所有这些外观都有相似的排字设计。
可以从 Font 对象获得三种不同的名称。逻辑字体名称 只是用来构造字体的名称。字体外观名称，或外观名称 是特定字体外观的名称，如 Helvetica Bold。系列名称 是字体系列的名称，用来确定多种外观（如 Helvetica）的排字设计。
Font 类表示字体外观集合中字体外观的实例，字体外观集合位于主机系统的系统资源中。例如，Arial Bold 和 Courier Bold Italic 是字体外观。有几个
Font 对象与字体外观相关，每个对象在大小、样式、变换和字体特征上都有所不同。
GraphicsEnvironment 类的 getAllFonts 方法返回系统中所有可用字体外观组成的数组。这些字体外观被作为
Font 对象返回，对象的大小为 1，具有恒等变换和默认字体特征。这些基本字体可以用来派生新的 Font 对象，使之具有变化的大小、样式、变换和字体特征，这些可以通过此类中的
deriveFont 方法实现。
Font 支持大多数 TextAttribute。这使得一些操作（如呈现带下划线的文本）变得更方便，因为没必要再显式构造一个
TextLayout 对象。通过使用 TextAttribute 值的 Map 来构造或派生属性，可以在 Font 上设置属性。
一些 TextAttributes 值是不可序列化的，因此尝试序列化具有这样的值的 Font 实例不会使它们获得序列化。这意味着从这样一个流实现序列化的 Font 不会等同于包含不可序列化属性的原始 Font。这应该是很少出现的一个问题，因为这些属性通常只使用在特殊情况下并且不可能被序列化。
FOREGROUND 和 BACKGROUND 使用 Paint 值。子类
Color 是可序列化的，而 GradientPaint 和 TexturePaint 是不可序列化的。
CHAR_REPLACEMENT 使用 GraphicAttribute 值。子类 ShapeGraphicAttribute 和
ImageGraphicAttribute 是不可序列化的。 INPUT_METHOD_HIGHLIGHT 使用 InputMethodHighlight 值，它是不可序列化的。请参阅
InputMethodHighlight。
创建 Paint 和 GraphicAttribute 的自定义子类的客户机可以使它们可序列化并避免此问题。使用输入方法高亮显示的客户机可以将这些转换为特定于平台的属性，以便在当前平台上高亮显示它们并在 Font 上设置它们，以此作为解决方法。
基于 Map 的构造方法和 deriveFont API 忽略了 FONT 属性，并且没有通过 Font 保留它；如果 FONT 属性可能存在，则应该使用 static
getFont(java.util.Map) 方法。有关更多信息，请参阅
TextAttribute.FONT。
一些属性会带来额外的呈现开销，并且可能调用布局。如果某一 Font 具有这样的属性，那么 hasLayoutAttributes
注：字体旋转可能导致文本基线也跟着旋转。为了应对这种（很少见的）可能性，可以指定字体 API 返回字体规格，并使参数“位于相对于基线的坐标中”。这将 ‘x‘ 坐标映射到沿基线的某段距离处（正 x 表示沿基线的正方向），将 ‘y‘ 坐标映射到位于 ‘x‘ 坐标的基线垂直方向的某段距离处（正 y 表示从基线向量顺时针旋转 90 度）。用于实现这些的 API 特别重要，它们被调出，就像具有“相对于基线的坐标”一样。
标签：
原文地址：http://blog.csdn.net/hpdlzu80100/article/details/52008599
