您的位置:首页 > 编程语言 > Java开发

Java的字体类详解(Font)-摘自Java API文档

2016-07-24 00:18 465 查看
字体是个非常平常的概念,以至于看到Java API文档对于字体的长篇大论的说明时,我突然感觉自己很无知。

以下是英文原文:

java.awt.Font

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.

Characters and Glyphs

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.

Physical and Logical Fonts

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.

Font Faces and Names

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 and TextAttribute

Font
supports most
TextAttribute
s. 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()
method will return true.

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

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
[/code] 方法将返回 true。

注:字体旋转可能导致文本基线也跟着旋转。为了应对这种(很少见的)可能性,可以指定字体 API 返回字体规格,并使参数“位于相对于基线的坐标中”。这将 'x' 坐标映射到沿基线的某段距离处(正 x 表示沿基线的正方向),将 'y' 坐标映射到位于 'x' 坐标的基线垂直方向的某段距离处(正 y 表示从基线向量顺时针旋转 90 度)。用于实现这些的 API 特别重要,它们被调出,就像具有“相对于基线的坐标”一样。


内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: