モジュール java.desktop
パッケージ java.awt

クラスFont

java.lang.Object
java.awt.Font
すべての実装されたインタフェース:
Serializable
直系の既知のサブクラス:
FontUIResource
public class Font extends Object implements Serializable
Fontクラスは、テキストを見えるように描画するために使用されるフォントを表します。 フォントは文字の連続をグリフの連続にマッピングするための情報、そしてそのグリフの連続をGraphicsやComponentオブジェクトに描画するための情報を提供します。

文字とグリフ

文字は英字、数字、句読点などのアイテムを抽象的に表すシンボルです。 たとえば、'g' (ラテン小文字のG)は文字です。

グリフは文字または一連の文字を描画するために使用される図形です。 ラテン文字のような単純な書記法では、通常1つのグリフが1つの文字に対応します。 ところがグリフと文字の対応は、一般的には1対1ではありません。 たとえば「á」(アクセント記号付きのラテン小文字のA)のような文字はそれぞれ「a」と「´」に対応する2つのグリフで表されます。 一方で2つの文字「fi」を、合字の1つのグリフで表すこともできます。 アラビア語、南アジア、および東南アジアの言語のような複雑な書記法では、文字とグリフの関係はもっと複雑になり、コンテキストに応じてグリフの選択や並べ替えが必要になります。 フォントは選択された文字セットの描画で必要なグリフの集合、および文字の連続を対応するグリフの連続にマッピングするために必要な表をカプセル化します。

物理フォントと論理フォント

Javaプラットフォームでは物理フォントと論理フォントを区別します。

物理フォントは実際のフォント・ライブラリであり、グリフ・データおよび文字シーケンスとグリフ・シーケンスのマッピング表を含みます。TrueTypeやPostScript Type 1などのフォント・テクノロジが使用されます。 すべてのJavaプラットフォームの実装でTrueTypeフォントがサポートされている必要があります。他のフォント・テクノロジのサポートは実装に依存します。 物理フォントにはHelvetica、Palatino、HonMinchoなどの任意のフォント名を使用します。 通常、各物理フォントは、ラテン文字だけ、または日本語と基本的なヨーロッパ系の言語だけなどのように、特定の書記法だけをサポートします。 有効な物理フォントのセットは設定によって異なります。 特定のフォントが必要な場合、アプリケーション側でフォントをバンドルし、createFontメソッドでインスタンス化できます。

論理フォントは、Javaプラットフォームで定義されるSerif、SansSerif、Monospaced、DialogおよびDialogInputの5つのフォント・ファミリです。すべてのJava実行環境でこの5つがサポートされている必要があります。 これらの論理フォントは実際のフォント・ライブラリではありません。 代わりに、論理フォント名はJava実行環境で物理フォントにマッピングされます。 マッピングは実装、そして通常ロケールに依存し、提供される外見やメトリックスもそれに応じて異なります。 通常はさまざまな文字をカバーするため、各論理フォント名が複数の物理フォントにマッピングされます。

LabelやTextFieldなどのピアAWTコンポーネントは、論理フォントだけを使用できます。

物理フォントまたは論理フォントを使用することの相対的な利点と欠点については、「Javaチュートリアル」ドキュメントの「物理フォントと論理フォント」を参照してください。

フォント・フェースとフォント名

Fontは、多くのフェース(heavy、medium、oblique、gothic、およびregularなど)を持つ場合があり、 これらすべてのフェースが、同じような文字体裁デザインを持っています。

Fontオブジェクトからは3つの異なる名称を取得できます。 論理フォント名は単なるフォント構築のための名称です。 フォント・フェース名は単にフォント名と呼ばれることもあり、Helvetica Boldなどの特定のフォント・フェース名を指します。 ファミリ名はフォント・ファミリの名称であり、複数のフェースの文字体裁デザインを決定します。たとえばHelveticaがこれに該当します。

Fontクラスは、ホスト・システムのシステム・リソースにあるフォント・フェースのコレクションの中の、あるフォント・フェースのインスタンスを表します。 たとえば、Arial BoldおよびCourier Bold Italicはフォント・フェースです。 サイズ、スタイル、変形体、およびフォントの特徴の違いにより、1つのフォント・フェースに関連付けられたFontオブジェクトは複数あります。

グリフは、論理フォントを実装するための適切なプラットフォーム・フォントがないなどのプラットフォームの制限により、リクエストされたプロパティ(例:フォントとスタイル)で常にレンダリングされるとはかぎりません。

GraphicsEnvironmentクラスのgetAllFontsメソッドは、システムで有効なすべてのフォント・フェースの配列を返します。 これらのフォント・フェースは、サイズ1、恒等変換、およびデフォルト・フォントの特徴を持つFontオブジェクトとして返されます。 ベースとなるこれらのフォントは、このクラスのderiveFontメソッドを介して、サイズ、スタイル、変形体、およびフォントの特徴が異なる新しいFontオブジェクトを派生させるために使用できます。

FontとTextAttribute

FontではほとんどのTextAttributeがサポートされます。 これにより、TextLayoutオブジェクトを明示的に構築する必要がなくなるため、下線付きテキストの描画などの操作が簡単になります。 TextAttribute値のMapを使用してフォントを構築するか派生させることによって、フォントに属性を設定できます。

一部のTextAttributesの値は直列化不可能なので、そのような値を持つFontのインスタンスを直列化しても、これらの値は直列化されません。 したがって、そのようなストリームから直列化復元されたフォントは、直列化不可能な属性を含んでいる元のフォントと等しいものにはなりません。 通常、これらの属性は特殊な状況でのみ使用され、直列化されることはまれなので、これが問題になることはほとんどありません。

  • FOREGROUNDとBACKGROUNDはPaint値を使用します。 サブクラスColorは直列化可能ですが、GradientPaintとTexturePaintは直列化不可能です。
  • CHAR_REPLACEMENTはGraphicAttribute値を使用します。 サブクラスShapeGraphicAttributeとImageGraphicAttributeは直列化不可能です。
  • INPUT_METHOD_HIGHLIGHTはInputMethodHighlight値を使用します。これらの値は直列化不可能です。 InputMethodHighlightを参照してください。

ユーザーがPaintとGraphicAttributeのカスタム・サブクラスを作成する場合は、これらを直列化可能にして、この問題を回避することができます。 ユーザーがインプット・メソッドのハイライトを使用する場合は、回避策として、現在のプラットフォームでそのハイライトのプラットフォーム固有属性に変換し、それをフォントに設定することができます。

MapベースのコンストラクタとderiveFont APIではFONT属性は無視され、フォントで保持されません。FONT属性が存在する場合は、static getFont(java.util.Map<? extends java.text.AttributedCharacterIterator.Attribute, ?>)メソッドを使用してください。 詳細は、TextAttribute.FONTを参照してください。

いくつかの属性は、追加の描画オーバーヘッドを発生させ、レイアウトを呼び出す可能性があります。 Fontがそのような属性を持っている場合、hasLayoutAttributes()メソッドはtrueを返します。

ノート: フォントを回転するとテキストのベースラインが回転することがあります。 このまれな可能性に対処するために、フォントAPIは指定に従って「ベースラインを基準にした座標で」メトリックスを返したりパラメータを受け取ったりします。 この場合、x座標はベースラインに沿った有効幅(正のxはベースラインに沿って進む方向)、y座標はxでのベースラインに対する垂線に沿った距離(正のyはベースライン・ベクトルから時計回りに90度の方向)にマップされます。 これが特に重要となるAPIは、「ベースラインを基準にした座標」を持つAPIとして示されています。

関連項目: