15. フォント

目次

  1. 概論
  2. フォントを指定する
    1. フォントのプロパティ
    2. フォントファミリ: 'font-family'
    3. フォントスタイル: 'font-style'、'font-variant'、'font-weight'、'font-stretch'
    4. フォントサイズ: 'font-size'、'font-size-adjust'
    5. フォントの簡略化プロパティ: 'font'
    6. 総称ファミリ
  3. フォントを選択する
    1. フォントを記述する
    2. フォントを選択するための記述子: 'font-family'、'font-style'、'font-variant'、'font-weight'、'font-stretch'、'font-size'
    3. フォントデータの範囲を限定するための記述子: 'unicode-range'
    4. 数値指定に基準を与えるための記述子: 'units-per-em'
    5. フォントを参照するための記述子: 'src'
    6. マッチングのための記述子: 'panose-1'、'stemv'、'stemh'、'slope'、'cap-height'、'x-height'、'ascent'、'descent'
    7. フォントを加工するための記述子: 'widths'、'bbox'、'definition-src'
    8. 位置合わせのための記述子: 'baseline', 'centerline', 'mathline', and 'topline'
    9. 記述例
  4. フォントの特性
    1. 概要
    2. フォントの完全名
    3. 文字座標系
    4. 中央ベースライン
    5. フォントの符号化
    6. フォントファミリ名
    7. グリフの幅
    8. 水平画線幅
    9. 大文字グリフの高さ
    10. 小文字グリフの高さ
    11. 下ベースライン
    12. 数学記号のベースライン
    13. 境界ボックスの限界
    14. アクセントを除いた状態におけるグリフの最高点
    15. アクセントを除いた状態におけるグリフの最低点
    16. Panose-1属性値
    17. ISO10646文字集合におけるグリフの範囲
    18. 上ベースライン
    19. 垂直画線幅
    20. 垂直画線の傾き
  5. フォントのマッチングアルゴリズム
    1. 数値とウェイト名を対応付ける
    2. マッチングの例

15.1 概論(Introduction)

文書のテキストを視覚的に表示する時、文字情報(抽象的な情報単位)を抽象グリフ(abstract glyphs)にマッピングする必要がある。 文字情報と抽象グリフは、前後関係に応じて様々な対応関係(1対1、1対多、多対多)を持つ。 グリフ(glyph)とは抽象グリフの実際の表現であり、活字のスタイル情報が反映されて、画面や紙面上にビットマップあるいはアウトライン形式で描画される。 フォント(font)とはグリフの集合体であり、すべてのグリフは、デザイン、大きさ、外観など、集合全体に共通する基調に従っている。 また、フォントには文字情報と抽象グリフの対応関係が含まれている。

視覚系のUAは、実際に文字を描画する前に以下を確認しなければならない:

CSS1とCSS2のどちらでも、文書作成者は、フォントに関する一連のプロパティを用いてフォントの特徴を指定する。

CSS2では、クライアント側にマッチするフォントが存在しない場合の、UAの処理方法が拡張された。 CSS1では、すべてのフォントがクライアントのシステムにあるものと仮定し、それらを単に名前によってのみ識別していた。 プロパティを通して代替フォントを指定することはできたが、それ以上のことをしようと思うと、総称名を用いる以外に他のフォントを候補に上げる手段は無かったのである(見た目が非常に似ているフォントを利用できる状況であっても、そのフォントは使えなかった)。

CSS2ではこういった仕組みをすべて変更し、以下の点についてはるかに自由がきくようしした:

CSS2では、クライアント側でのフォントのマッチングを大いに改善した。 フォントの加工や、プログレシブ描画、Webからのフォントのダウンロードなどを可能にした。 こういった強化機能を総称して「WebFonts」と呼ぶ。

CSS2のフォントモデルでは、CSS1と同様に、各UAが処理時に参照するデータベースを考える。 CSS1でもデータベースについては言及していたが、その内容の詳細には触れなかった。 CSS2ではデータベースに納める情報を定義し、スタイルシート設計者がその情報を操作できるようにする。 特定のフォントで文字を表示する要求があると、UAはまず指定内容に最も適したフォントをデータベースから選び出す(フォントのマッチングアルゴリズムに従う)。 フォントが決まると、そのフォントデータをローカルあるいはWebから検索する。 そして、取得したグリフを用いて文字を表示するのである。

このモデルの観点から、フォントの特定を2段階に分けることにした。 まず、文書作成者が使いたいフォントを指定する過程を第1段階とする。 そして、クライアント側のUAが、要求に最も適したフォントを選び出すのが第2段階である。

UAがフォントのデータベースを構築する手段については、本仕様の対象外である。 何故なら、データベースの実装方法は、OS、ウィンドウシステム、クライアントなど、様々な要因に依存するからである。

15.2 フォントを指定する(Font specification)

CSSフォントモデルの前半は、UAに使って欲しいフォントを指定する方法についてである。 まず第1に、フォントを名前で指定するのが明確な方法であるように思える。 ここで名前というのは一連の文字列であるが、その文字列は(様々な特徴を表す)複数のパートに分かれているのが普通である。 たとえば「BT Swiss 721 Heavy Italic」など。

残念なことに、名前に基づいたフォントの分類には、広く普及した明確な方法が存在しない。 あるフォントファミリで使われている術語が、別のファミリでは通用しないことがある。 たとえば「italic」という術語は斜体字を表すのに用いるが、斜体字を表す術語には他にもObliqueSlantedInclineCursiveKursivなどがある。 同様に、フォントの名前はウェイトを表す術語を含んでいるのが普通であるが、こういった術語の主な役割は、単独のファミリ内で異なる重みの書体を区別することである。 したがって、ウェイトの呼び名には一貫した体系が存在せず、ある単独の術語でもその使用法は多岐に亘っている。 たとえば、あるファミリで「通常」とされている重みによっては、RegularRomanBookMediumSemi-BoldDemi-BoldBoldBlackなど様々な術語がボールド体を表し得る。

こういった名前体系の欠陥のせいで、ある1点のみの相違(より太く、など)を強調するための汎用的な書体名が使えなくなっている。

以上の理由から、CSSでは別のモデルを採用する。 このモデルでは、単独のフォント名ではなく、フォントに関する一連のプロパティを通してフォントを要求する。 これらのプロパティに指定された値が、フォントを選択する際の基準を形成するのである。 フォントのプロパティは「より太く」のように個別に変更することが可能であり、変更した値はデータベースから再度フォントを選択する際に活用される。 こうすればスタイルシート設計者や実装者にとって納得行く結果が得られるだろう。

15.2.1 フォントのプロパティ(Font specification properties)

CSS2では以下の特徴に基づいてフォントを指定する:

Font family
テキストを表示するのに用いるフォントファミリのこと。 フォントファミリとは、デザインの一貫性を保つために組み合わせて用いられる、フォントの集合である。 ファミリ内には、italic、bold、condensed、small-capsなどの書体がある。 ファミリの種類には、Helvetica、New Century Schoolbook、Kyokasho ICA L、などがあり、ファミリの名称には欧文以外の文字が含まれていてもよい。 また、各ファミリはひげ付き、文字幅詰め、筆記体、飾り文字などの特徴に従って数種類に分類される。
Font style
テキストを通常体、イタリック体、斜体のうちいずれを用いて表示したいかを示す。 イタリック体とは、同じファミリの通常体に比べて相対的に続け書きになっている書体を指すのであり、いわゆるスクリプト(元々の筆記体)を指すのではない。 斜体とは同じファミリの通常体をそのまま傾けた書体であり、サンセリフ系ファミリの1書体として存在することが多い。 以上の定義により、ファミリの通常体からして傾いている書体をobliqueに分類したり、普通のギリシャ書体をitalicに分類するのを回避している。
Font variant
テキストの小文字を、通常グリフとスモールキャピタルグリフのうちどちらを用いて表示したいかを示す。 どちらか片方のみに対応しているフォントもあれば、両方のグリフを含むフォントも存在する。 このプロパティを用いると、使いたい方のフォントを要求できる。 1つのフォントが両方のグリフを含んでいても、使いたい方のグリフだけを抽出できる。
Font weight
テキストを表示する時に用いるグリフの、ファミリ内における相対的な太さ(ウェイト)のこと。
Font stretch
テキストを表示する時に用いるグリフの、ファミリ内における相対的な字幅のこと。
Font size
行間を詰めた時の(CSS的に言えば、仮に'line-height'の値を'font-size'と同じにした時の)隣接ベースライン間距離を基準にしたフォントサイズのこと。

'font-size'以外のプロパティでは、相対単位emとexは当該要素の文字サイズを参照する。 一方、'font-size'では親要素の文字サイズを参照する。 詳細は[4.3.2 長さ]を参照のこと。

CSSのフォントプロパティは、テキストに適用して欲しい外観を記述するのに用いる。 一方フォント記述子は、その要求を満たす適切なフォントが選択できるように、利用可能なフォントの特徴を記述するために用いる。 フォントの特徴分類に関してはフォント記述子を参照されたい。

15.2.2 フォントファミリ(Font family: the 'font-family' property)

'font-family'
Value:  [[ <family-name> | <generic-family> ],]* [<family-name> | <generic-family>] | inherit
Initial:  depends on user agent
Applies to:  all elements
Inherited:  yes
Percentages:  N/A
Media:  visual

このプロパティは、フォントファミリ名と総称ファミリ名の優先順リストを指定する。 単独のフォントだけで文書内の全文字に対するグリフが得られないこともあるし、あらゆるフォントがシステムに存在するとも限らない。 これらの問題を解決するために、このプロパティでは、同じスタイルと大きさを有するフォントのリストを指定できる。 リストに挙げられたフォントは、各文字に対するグリフを含んでいるかどうかを順に検証される。 このリストのことをフォントセット(font set)と呼ぶ。

たとえば、英語と数学記号が混在しているテキストには、その2つのフォントから成るフォントセットが必要になる。 次の例は、ラテン系文字、日本文字、数学記号が混在するテキストに適している:

BODY { font-family: Baskerville, "Heisi Mincho W3", Symbol, serif }

ラテン系文字のグリフは「Baskerville」というフォントから、日本文字のグリフは「Heisi Mincho W3」というフォントから、数学記号のグリフは「Symbol」というフォントから、それ以外のグリフは総称ファミリ「serif」から得られるだろう。

総称ファミリは、フォントセットに含まれる他のフォントが利用不可能な時に用いられる。 多くのフォントには表示できない文字を表すグリフ(中ぬけの四角など)が存在するが、フォントセット末尾のフォント以外では、このグリフをマッチングの対象にすべきではない。

フォントファミリには2種類の名前がある:

<family-name>
選択するフォントファミリの名称。 前の例だと「Baskerville」「Heisi Mincho W3」「Symbol」などに該当する。 空白類文字を含むファミリ名は引用符で括った方が無難である。 引用符を省略すると、フォント名の直前後に出現する空白類文字無視され、フォント名の途中に連続して出現する空白類文字は、単独のスペースに変換されてしまう。
<generic-family>
総称ファミリ名には、serif、sans-serif、cursive、fantasy、monospaceの5種類がある。 各総称ファミリについては[15.2.6 総称フォントファミリ]を参照のこと。 総称ファミリ名はキーワードなので引用符で括ってはならない。

文書作成者には、最後の強力な選択肢として、総称ファミリ名を指定するよう推奨する。

例を挙げておこう:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
  <HEAD>
    <TITLE>Font test</TITLE>
    <STYLE type="text/css">
      BODY { font-family: "new century schoolbook", serif }
    </STYLE>
  </HEAD>
  <BODY>
   <H1 style="font-family: 'My own font', fantasy">Test</H1>
    <P>What's up, Doc?
  </BODY>
</HTML>

CSS2の豊富なセレクタを利用して、言語に応じたフォントを用意することも可能である。 たとえば、中国語と日本語にはUnicodeのコード番号を共有する文字が存在するが、両言語では対応する抽象グリフが同じではない。

*:lang(ja-jp) { font: 900 14pt/16pt "Heisei Mincho W9", serif }
*:lang(zh-tw) { font: 800 14pt/16.5pt "Li Sung", serif }

こうすれば、各要素の言語 -- 日本語と中国語 -- に応じて適切なフォントを要求できる。

15.2.3 フォントスタイル(Font styling: the 'font-style', 'font-variant', 'font-weight' and 'font-stretch' properties)

'font-style'
Value: normal | italic | oblique | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual

このプロパティは、フォントファミリの中から通常体(romanとかuprightなどと呼ばれることもある)、イタリック体、斜体のいずれかを要求する。 各値は以下の様な意味を持つ:

normal
データベースで「normal」に分類されたフォントを要求する。
oblique
データベースでobliqueに分類されたフォントを要求する。 フォント名にOblique、Slanted、Incline、などの術語が含まれるとobliqueに分類されることが多い。 ただし、実際には通常体を強制的に傾けて斜体字を生成してもよい。
italic
データベースでitalicに分類されたフォントを要求する。 ただし、該当するフォントが存在しなければobliqueと分類されたものでもよい。 フォント名にItalic、Cursive、Kursiv、などの術語が含まれるとitalicに分類されることが多い。

次の例では、H1、H2、H3要素のテキストが斜体字で表示される。 ただし、H1要素内の強調テキストだけは通常体で表示される。

H1, H2, H3 { font-style: italic }
H1 EM { font-style: normal }
'font-variant'
Value:  normal | small-caps | inherit
Initial:  normal
Applies to:  all elements
Inherited:  yes
Percentages:  N/A
Media:  visual

スモールキャピタルのフォントは、小文字のグリフとして縦幅比のやや異なる小さな大文字を用いる。 このプロパティは、活字ケースが2種類存在する用字系(たとえばアルファベットには大文字と小文字がある)に対してスモールキャピタルのフォントを要求する。 ただし、活字ケースが1種類のみの用字系(こういった用字系は世界中に多く存在する)に対しては視覚効果がない。 各値は以下の様な意味を持つ:

normal
small-capsに分類されていないフォントを要求する。
small-caps
small-capsに分類されたフォントを要求する。 本物のスモールキャピタルが利用できなければ、通常フォントの小文字を縮小した大文字で置換するなどして、フォントを疑似生成すべきである。 それもできなければ、最終的にはすべて大文字のみで表示してもよい。

Example(s):

次の例では、H3要素をスモールキャピタルで表示し、強調語は更に斜体で表示する:

H3 { font-variant: small-caps }
EM { font-style: oblique }

全テキストを大文字に変換するという効果に限定すれば、'text-transform'で同じ効果を得られる。

'font-weight'
Value:  normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | inherit
Initial:  normal
Applies to:  all elements
Inherited:  yes
Percentages:  N/A
Media:  visual

このプロパティは希望するウェイトのフォントを要求する。 各値は以下の様な意味を持つ:

100 - 900
これらの数値はウェイトを相対的に順序付けしており、数値が大きければ、より重いフォントか、あるいは少なくとも同じ重みのフォントを要求する。
normal
'400'と同じ。
bold
'700'と同じ。
bolder
継承したフォントより重いフォントに対応する数値の中で、最も近いウェイトを要求する。 該当するウェイトが存在しなければ、数値を単に1段階(すなわち100)大きくするだけでフォントは変更しない。 継承値からして900である場合、数値さえも変更しない。
lighter
継承したフォントより軽いフォントに対応する数値の中で、最も近いウェイトを要求する。 該当するウェイトが存在しない場合、数値を単に1段階(すなわち100)小さくするだけでフォントは変更しない。 継承値からして100である場合、数値さえも変更しない。
P { font-weight: normal }   /* 400 */
H1 { font-weight: 700 }     /* bold */
BODY { font-weight: 400 }
STRONG { font-weight: bolder } /* 500 if available */

子供要素はウェイトの算出値(すなわち数値)を継承する。

'font-stretch'
Value:  normal | wider | narrower | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | inherit
Initial:  normal
Applies to:  all elements
Inherited:  yes
Percentages:  N/A
Media:  visual

このプロパティは、フォントファミリの中から希望する字幅のフォントを要求する。 絶対キーワードは、字幅の狭い方から以下の様に順序付けされる:

  1. ultra-condensed
  2. extra-condensed
  3. condensed
  4. semi-condensed
  5. normal
  6. semi-expanded
  7. expanded
  8. extra-expanded
  9. ultra-expanded

相対キーワード'wider'は、継承値より1段階広い字幅の値を設定する。 ただし、継承値が'ultra-expanded'である場合は変更しない。 相対キーワード'narrower'は、継承値より1段階狭い字幅の値を設定する。 ただし、継承値が'ultra-condensed'である場合は変更しない。

15.2.4 フォントサイズ(Font size: the 'font-size' and 'font-size-adjust' properties)

'font-size'
Value:  <absolute-size> | <relative-size> | <length> | <percentage> | inherit
Initial:  medium
Applies to:  all elements
Inherited:  yes, the computed value is inherited
Percentages:  refer to parent element's font size
Media:  visual

このプロパティは、行間を詰めてみた時のベースライン間距離としてフォントサイズを指定する。 各値は以下の様な意味を持つ:

<absolute-size>
これらのキーワードは、UAによって計算・保持されているフォントサイズ対照表を参照する。 可能な値は以下の通り:

[ xx-small | x-small | small | medium | large | x-large | xx-large ]

隣接するキーワードの、コンピュータ画面上における推奨スケーリング係数は1.2である。 たとえば、'medium'が12ptに対応するなら'large'は14.4ptである。 媒体が変わればスケーリング係数を変更してもよい。 また、UAはフォントサイズ対照表を計算する際、そのサイズでフォントの質が極端に悪くならないか、そのサイズに該当するフォントが存在するのか、などを考慮すべきである。 つまりフォントファミリごとに別々の対照表を準備してよい。

注。 CSS1では隣接キーワードの推奨スケーリング係数は1.5だったが、ユーザの経験からこの値は大きすぎることが判明した。

<relative-size>
これらのキーワードは、親要素のフォントサイズに対して相対的に対照表を解釈する。 可能な値は以下の通り:

[ larger | smaller ]

たとえば親要素のフォントサイズが'medium'だとすると、'larger'は'large'と解釈される。 親要素の値が対照表にある値とかけ離れている場合、対照表に新規の値を挿入するも、もっとも近い値へ丸めてしまうもUAの自由である。 場合によっては、対照表の最も外側に新規の値を挿入するはめになるだろう。

<length>
フォントサイズの絶対値を長さで指定する(UAの対照表からは独立している)。 負の値は不正である。
<percentage>
親要素のフォントサイズに対する相対パーセント値を指定する。 パーセント値や相対単位を活用することで、CSSは更に強力かつ柔軟になる。

'font-size-adjust'との兼ね合いを考慮したり、計算したフォントサイズが利用不能な場合があるので、このプロパティの算出値実効値は異なることが多い。

子供要素は'font-size'の算出値を継承する。 (あるいは'font-size-adjust'の効果を念頭に置く)

P { font-size: 12pt; }
BLOCKQUOTE { font-size: larger }
EM { font-size: 150% }
EM { font-size: 1.5em }
'font-size-adjust'
Value:  <number> | none | inherit
Initial:  none
Applies to:  all elements
Inherited:  yes
Percentages:  N/A
Media:  visual

活字ケースが2種類存在する用字系では、フォントサイズの印象や文字の読み易さは、'font-size'そのものの値と余り関係ない。 それよりむしろ'x-height'の値、いやそれ以上に両者の縦幅比(フォントサイズをx-heightで割った値)が重要である。 縦幅比が大きければフォントサイズが小さくても読み易く、逆に縦幅比が小さければフォントサイズを初期値より少し小さくするだけで読みにくくなるようである。 したがって、フォントサイズだけを見て安直に代替フォントを決めると、読みにくいことこの上ない文字になってしまうだろう。

たとえば一般的なVerdanaというフォント、これは縦幅比0.58であり、フォントサイズを100とすればx-heightは58になる。 比較対象としてTimes New Romanを挙げると、これは縦幅比0.46である。 両者のうち、Verdanaは小さい文字でも読み易さを維持できることが多い。 しかし、Times New Romanを用いるべき箇所で同じ大きさのVerdanaを代用品にしようものなら、文字が大きすぎる印象を与えてしまうだろう。

このプロパティを用いれば、フォントセットの中で最初の選択肢だったフォントのx-heightを、代替フォントでも維持し続けることができる。 各値は以下の様な意味を持つ:

none
フォントのx-heightを維持しない。
<number>
縦幅比を指定する。 指定する数字は、フォントセットの最初の選択肢となるフォントの縦幅比である。 選択対象となる各フォントごとに、以下の公式に従って拡大・縮小率を計算する:
  y(a/a') = c

ただし:

y  = 最初の選択肢になるフォントの'font-size'の値
a  = 最初の選択肢になるフォントの縦幅比
a' = 現在選択中であるフォントの縦幅比
c  = 現在選択中のフォントに適用すべき'font-size'の値

たとえば、14pxのVerdana(縦幅比0.58)を使いたかったのにそれは利用不可能であることが判明し、代わりに縦幅比0.46の代替フォントが利用可能だとしよう。 上の公式より、代替フォントのフォントサイズは14 * (0.58/0.46) = 17.65pxにすればよいことになる。

フォントサイズの調整は'font-size'実効値を計算する段階で行う。 つまり、'font-size'の継承には調整前の算出値を用いること。

次の画像は、様々な書体を同じサイズ(11pt、72pt-per-inch)にラスタライズしたものである。 縦幅比も併記した。 実際は総て同じサイズであるにも拘わらず、縦幅比が大きいほど文字が大きく見えていることと思う。 このフォントサイズだと、縦幅比が極端に小さい書体は非常に読みにくい。

12ptフォントの比較

次の画像は、Verdanaを最初の選択肢とした時の、'font-size-adjust'による調整結果である。 併記した数字は拡大倍率である。 調整のおかげでどの書体も殆ど同じ大きさに見えるかもしれないが、これでも実際のフォントサイズには2倍以上の差がある。 また、この調整法を用いることによって、行の長さもうまく調整されることが見て取れるだろう。

調整済みフォントの比較

15.2.5 フォントの簡略化プロパティ(Shorthand font property: the 'font' property)

'font'
Value:  [ [ <'font-style'> || <'font-variant'> || <'font-weight'> ]? <'font-size'> [ / <'line-height'> ]? <'font-family'> ] | caption | icon | menu | message-box | small-caption | status-bar | inherit
Initial:  see individual properties
Applies to:  all elements
Inherited:  yes
Percentages:  allowed on 'font-size' and 'line-height'
Media:  visual

'font'は簡略化プロパティであり、'font-style''font-variant''font-weight''font-size''line-height''font-family'という6つのプロパティを1箇所に設定できる。 ただし単なる簡略化プロパティとはやや異なり、これについては後で述べる。 このプロパティの構文は、フォントに関する複数の性質を記述するための、印刷物分野における慣習的な簡略表記法に則っている。

このプロパティを用いると、まずフォント関連のプロパティ('font-stretch''font-size-adjust'も含む)は総て初期値にリセットされ、それから指定された値を割り当てなおす。 使用可能な値及び初期値については個々のプロパティ定義を参照せよ。 また、この簡略化プロパティで'font-stretch''font-size-adjust'の値を初期値以外に変更できないのは、下位互換性を考慮してのことである。 これらの値を変更したい場合は個別に対処してもらいたい。

P { font: 12pt/14pt sans-serif }
P { font: 80% sans-serif }
P { font: x-large/110% "new century schoolbook", serif }
P { font: bold italic large Palatino, serif }
P { font: normal small-caps 120%/120% fantasy }
P { font: oblique 12pt "Helvetica Nue", serif; font-stretch: condensed }

2番目の規則において、フォントサイズのパーセント値('80%')は親要素のフォントサイズを参照する。 一方3番目の規則においては、行の高さのパーセント値('110%')は当該要素自身のフォントサイズを参照する。

最初3つの規則では'font-variant''font-weight'の値を明示していないので、これらのプロパティは初期値(normal)を取る。 また「new century schoolbook」というファミリ名はスペースを含んでいるので引用符で括ってある。 4番目の規則では'font-weight'を'bold'、'font-style'を'italic'に設定しており、'font-variant'の値は明示されていなくても初期値の'normal'になる。

5番目の規則では、'font-variant'を'small-caps'に、'font-size'を親要素の120%に、'line-height'をフォントサイズの120%に、'font-family'を'fantasy'に設定している。 キーワード'normal'は残った'font-style''font-weight'に適用される。

6番目の規則では'font-style''font-size''font-family'を明示的に設定しており、それ以外のフォント関連プロパティは初期値を取る。 また、'font'では設定できない'font-stretch'の値を別個に'condensed'と指定している。

以下の値によってシステムフォントも活用できる:

caption
The font used for captioned controls (e.g., buttons, drop-downs, etc.).
icon
アイコンの名前を表示するフォント
menu
メニューに用いるフォント(ドロップダウンメニューなど)
message-box
ダイアログボックスに用いるフォント
small-caption
The font used for labeling small controls.
status-bar
ステータスバーに用いるフォント

システムフォント値は、ファミリ、サイズ、ウェイト、スタイルなど全体の値を同時に設定する。 必要ならば個々の値を上書き変更することも可能である。 指定されたシステムリソースにフォントが存在しないプラットフォームでは、UAが適切な代替フォントを用意するか、UAのデフォルトフォントを使用すべきである。 たとえば、'caption'のフォントを小さくして'smallcaption'に用いるなど。 OSの設計上システムフォントの性質(プロパティ)を細部までユーザ側で操作できない場合、それらのプロパティには初期値を設定すべきである。

システムフォントが指定できるのは'font'だけであり、この役割は'font-family'では代用できない。 これが、単なる簡略化プロパティとはやや異なると言った理由である。 'font'は個々のプロパティをまとめる以上の役割を果たすのである。 しかも、システムフォントによって値を割り当てた後、'font-weight'などのプロパティを別個に上書き変更することも可能なのである。

BUTTON { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
BUTTON P { font: menu }
BUTTON P EM { font-weight: bolder }

たとえば、あるシステムでドロップダウンメニューに9pt、ウェイト600のCharcoalというフォントを利用しているとしよう。 BUTTON要素の子孫にあたるP要素は、下の規則が設定されたかのように表示される:

BUTTON P { font: 600 9pt Charcoal }

'font'を用いると値を明示しないプロパティは総て初期値にリセットされるので、この規則は以下の宣言と等価である:

BUTTON P {
  font-style: normal;
  font-variant: normal;
  font-weight: 600;
  font-size: 9pt;
  line-height: normal;
  font-family: Charcoal
} 

15.2.6 総称ファミリ(Generic font families

総称ファミリはいざという時の最終選択肢であり、指定したフォントが選択不可能な場合に、スタイル設計者の意図を最低限反映するための仕組みである。 これは予備手段なので、最適な体裁効果を得るための具体的なフォント名はやはり指定しておくべきである。

あらゆるCSSの実装系には5つの総称ファミリが定義されている(とは言っても、各総称ファミリに必ずしも別々のフォントを対応させる必要はない)。 総称ファミリに対応させるフォントについては、UAの依存環境が許す範囲内で各総称ファミリの特徴をできるだけ反映したものをデフォルトにすべきである。 【訳注:正確には「あらゆる実装系」ではなく「あらゆる視覚実装系」かと思いますが。】

UAは各総称ファミリに対応するフォントをユーザ側で変更可能にしておくよう推奨する。

serif

CSSで言うserif系のグリフとは、線の先端が「撥ね」ていたり、裾が太く/細くなっていたり、実際にひげ飾り(slab serifsなども含む)が付いていたりするグリフを指す。 serif系のフォントは多くの場合プロポーショナルフォントであり、sans-serif系に比べて線の太い/細いが目立ち易い。 CSSでは「seirf」という総称ファミリを用字系に関わらず適用するが、用字系によっては別の呼び方が定着している場合もあるだろう。 たとえば日本だと「Mincho」、中国だと「Sung」あるいは「Song」、韓国だと「Pathang」といった呼び方がある。 「serif」という総称ファミリは、こういった別の呼び方をするフォントも含むものとする。

この定義にあてはまるフォントには、たとえば以下のものがある:

欧文
Times New Roman, Bodoni, Garamond, Minion Web, ITC Stone Serif, MS Georgia, Bitstream Cyberbit
ギリシア文字 Bitstream Cyberbit
キリル文字 Adobe Minion Cyrillic, Excelcior Cyrillic Upright, Monotype Albion 70, Bitstream Cyberbit, ER Bukinst
ヘブライ文字 New Peninim, Raanana, Bitstream Cyberbit
日本語 Ryumin Light-KL, Kyokasho ICA, Futo Min A101
アラビア文字 Bitstream Cyberbit
チェロキー文字 Lo Cicero Cherokee

sans-serif

CSSで言うsans-serif系のグリフとは、線の先端が「止め」になっていて、裾の広がりやひげによる装飾が付いていないグリフを指す。 sans-serif系のフォントは多くの場合プロポーショナルフォントであり、serif系に比べて線の太い/細いが目立たない。 CSSでは「sans-seirf」という総称ファミリを用字系に関わらず適用するが、用字系によっては別の呼び方が定着している場合もあるだろう。 たとえば日本だと「Gothic」、中国だと「Kai」、韓国だと「Totum」あるいは「Kodic」といった呼び方がある。 「sans-serif」という総称ファミリは、こういった別の呼び方をするフォントも含むものとする。

この定義にあてはまるフォントには、たとえば以下のものがある:

欧文 MS Trebuchet, ITC Avant Garde Gothic, MS Arial, MS Verdana, Univers, Futura, ITC Stone Sans, Gill Sans, Akzidenz Grotesk, Helvetica
ギリシア文字 Attika, Typiko New Era, MS Tahoma, Monotype Gill Sans 571, Helvetica Greek
キリル文字 Helvetica Cyrillic, ER Univers, Lucida Sans Unicode, Bastion
ヘブライ文字 Arial Hebrew, MS Tahoma
日本語 Shin Go, Heisei Kaku Gothic W5
アラビア文字 MS Tahoma

cursive

CSSで言うcursive系(漢字だと草書に近い)のグリフとは、続け書きになっていて単なるイタリック書体以上に筆記的特徴を備えたグリフを指す。 グリフは部分的にあるいは完全につながっており、普通に印刷される文字よりも手書き/毛筆らしく見える。 用字系によっては、たとえばアラビア文字のフォントなどは大半がcursive系である。 CSSでは「cursive」という総称ファミリを用字系に関わらず適用し、「Chancery」「Brush」「Swing」「Script」など別の呼び方が定着しているフォントもこれに含むものとする。

この定義にあてはまるフォントには、たとえば以下のものがある:

欧文 Caflisch Script, Adobe Poetica, Sanvito, Ex Ponto, Snell Roundhand, Zapf-Chancery
キリル文字 ER Architekt
ヘブライ文字 Corsiva
アラビア文字 DecoType Naskh, Monotype Urdu 507

fantasy

CSSで言うfantasy系のフォントとは、装飾がメインになっているものの文字の表現を失ってはいないフォントを指す。 文字を表現しない絵と記号「だけ」のフォントとは異なる。 例を挙げると:

欧文 Alpha Geometrique, Critter, Cottonwood, FB Reactor, Studz

monospace

monospace系フォントであるための唯一の必要条件は、全グリフが同じ固定幅を有するということだけである(アラビア文字などの筆記体フォントにとっては妙なことになるが)。 手作業でタイプライタを打つのと似た雰囲気が得られ、コンピュータコードのサンプルを添える場合などに用いられることが多い。

この定義にあてはまるフォントには、たとえば以下のものがある:

欧文 Courier, MS Courier New, Prestige, Everson Mono
ギリシア文字 MS Courier New, Everson Mono
キリル文字 ER Kurier, Everson Mono
日本語 Osaka Monospaced
チェルキ− Everson Mono

15.3 フォントを選択する(Font selection)

CSSフォントモデルの後半は、文書作成者の指定や現環境での利用可能フォント、それにその他様々な諸条件に基づいて、実際に利用するフォントをUAが選択する仕組みについてである。 フォントのマッチングアルゴリズムについての詳細は別の節で述べる。

フォントの選択には4通りの動作がある。 名前によるマッチング、賢いマッチング、フォントの加工、それにダウンロードである。

名前によるマッチング
存在するアクセス可能なフォントのうち、ユーザの要求と一致する名前のフォントを選択する。 ただし、外観やメトリックにまで要求を反映させる必要はないので、文書作成者が意図したフォントとクライアントのシステム上で選択されるフォントが異なってもよい。 マッチングに活用する情報はファミリ名も含めてCSSのプロパティのみから得られる。 これはCSS1で採用されていた唯一の方式である。
賢いマッチング
存在するアクセス可能なフォントのうち、ユーザの要求に最も近い外観のフォントを選択する。 ただし、必ずしもユーザが要求するメトリックを反映させる必要はない。 マッチングに活用する情報には、フォントの種類(テキストなのか記号なのか)、装飾の有無、ウェイト、大文字の高さ、x-height、アセンダ、ディセンダ、傾き具合などがある。
フォントの加工
外観だけでなくメトリックについてもユーザの要求を反映できるように、UAがフォントを加工する。 フォントの加工に際しては、マッチングで活用する情報以外にも様々なパラメータの正確な値を必要とすることが多い。 特に要求したフォントのレイアウト情報を維持したい場合、横幅の正確なメトリックや、代用グリフとその位置に関する情報は必要性が大きい。
ダウンロード
最終的に、UAはフォントをWebからダウンロードしてもよい。 この手段は画像や音声、アプレットなどを取ってきて文書に表示する手続きと似たようなもので、ページを表示するまでに遅れが生じてしまうこともある。

プログレシブ描画(progressive rendering)とは、フォントのダウンロードと、それ以外の手段との組み合わせである。 最初は一時的に(名前によるマッチング、賢いマッチング、フォント加工のうちいずれかを活用して選択した)代用のフォントで文字を表示し、要求されたフォントのダウンロードが完了するまでの間、ユーザが内容を読めるようにしておくのである。 目的のフォントが無事ダウンロードできれば、代用のフォントを取り除いて(できれば文書を流し込みなおさずに)置換する。

- プログレシブ描画で実際に利用するフォントをロードする際、内容の再レイアウトを避けるためには(実際に利用する)フォントのメトリック情報が必要になる。 このメトリック情報は多すぎると却って厄介なので、1つのフォントに対する指定は文書内で1度限りにすべきである。

15.3.1 フォントを記述する(Font Descriptions and @font-face)

フォント記述の役割は、文書作成者の指定とフォントデータを仲介することである。 フォントデータとは、テキストを整形したり、文字情報に対応させた抽象グリフを描画したりするのに必要なデータ(実際のスケーラブルなアウトライン、ビットマップ情報)のことである。 そうして定義を記述したフォントは、スタイルシートのプロパティによって参照する。

フォント記述は例のデータベースに付け加えられ、関連するフォントデータを選択する際に活用される。 フォント記述には様々な記述子が含まれ、Web上でのフォントデータのありかだとか、そのフォントデータの特色などを示している。 また、フォントのプロパティを特定のフォントデータに結び付ける際にも記述子が必要になる。 記述の詳細度については、フォントの名称を与えるだけでもよいし、グリフ幅の一覧を掲げてもよい。

フォント記述子は以下の 3種類に分類できる:

  1. フォント記述をCSSで実際に活用するためのもの。 (これらは対応するCSSのプロパティと同じ名称である)
  2. フォントデータのありかを示すURI。
  3. フォントの特徴を更に限定して、フォント記述をフォントデータに結び付けるもの。

あらゆるフォント記述は@font-face規則を通して行われる。 その一般形は:

@font-face { <font-description> }

ここで<font-description>の形式は以下の通り:

記述子: 値;
記述子: 値;
[...]
記述子: 値;

@font-faceにおいては、あらゆるフォント記述子が値を与えられるものとする。 すなわち、@font-faceの中で値が明示されない場合は、本仕様の各記述子定義に示す初期値が仮定されるのである。 なお、フォント記述子は各@font-faceにのみ関連付けられるのであって、構造化言語の要素に対応するわけではない。 つまり「記述子がどの要素に適用されるのか?」とか「記述子の値は子供要素に継承されるのか?」とかいう話は的外れである。

利用可能なフォント記述子の一覧は別の章で与える。

ここの例では「Robson Celtic」というフォントを定義して、HTML文書の内部スタイルシートから参照してみる。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
  <HEAD>
    <TITLE>Font test</TITLE>
    <STYLE TYPE="text/css" MEDIA="screen, print">
      @font-face {
        font-family: "Robson Celtic";
        src: url("http://site/fonts/rob-celt")
      }
      H1 { font-family: "Robson Celtic", serif }
    </STYLE>
  </HEAD>
  <BODY>
    <H1> This heading is displayed using Robson Celtic</H1>
  </BODY>
</HTML>

STYLE要素に含まれる規則により、すべてのH1要素で「Robson Celtic」というフォントファミリを使うことになる。

CSS1の実装系なら、まずファミリ名「Robson Celtic」及びその他のプロパティにマッチするフォントをクライアントから探し出そうとする。 見つからなければ、必ず存在することになっているUA依存のserif系フォントを採用することになる。

CSS2の実装系なら、まず@font-faceを調べて「Robson Celtic」を定義しているフォント記述を探し出す。 上の例ではこれに該当する@font-faceが存在しており、そこにはあまり多くのフォントデータが含まれていないけれども、取り敢えず文書の表示に用いるフォントの検索先URIは得られる。 なお、ダウンロードしたフォントは他のアプリケーションから利用可能な状態にすべきではない。 マッチする@font-faceが存在しなければ、UAはCSS1の実装系と同様の手段でマッチングを試みる。 【訳注:と書いてあるが、正しく実装すれば最悪でも初期値にはマッチするはずである】

「Robson Celtic」というフォントが既にクライアントのシステムにインストールしてあれば、マッチングアルゴリズムの章でも述べる通り、データベースには既にそのエントリが追加済みであろう。 この場合、上例のような状況でもローカルのフォントが優先的にマッチする。

@font-face構文の内部を解析できないCSS1の実装系は、定義の開き括弧に遭遇するとそれに対応する閉じ括弧までを無視する。 この動作は、CSS上位互換解析に適合するには必須である。 パーサが@font-face構文を無視するのにエラーを出す必要はない。

フォント記述子をフォントデータから分離したことには、フォントの選択機構や代替機構以上の利点がある。 データの管理や複製という観点から見ると、フォントデータを直接操作するよりは記述子を利用した方がはるかに制約が少ないのである。 すなわち、フォント定義をローカル独自にインストールしておくもよし、頻繁に参照されるフォント定義をキャッシュしておくのも可能である。 これなら、Webを通してフォント定義にアクセスするのは各定義につき1度きりで済む。

同じ記述子が重複する場合、最後に出現する記述子のみを適用し、残りはすべて無視しなければならない。

同様に、UAが認識できない、もしくはUAにとって意味の無い記述子は無視しなければならない。 次版以降のCSSで、フォントの代用、マッチング、加工などを改善するために新たな記述子が加わるかもしれないからである。

15.3.2 フォントを選択するための記述子(Descriptors for Selecting a Font: 'font-family', 'font-style', 'font-variant', 'font-weight', 'font-stretch' and 'font-size')

以下の記述子は各々フォントのプロパティと同じ名称になっており、単独の値、もしくはコンマで区切った値のリストを取る。

このリストに含まれる記述子の値【訳注:もちろんリストの要素が1つだけの場合も含む】は、特に注記しない限り対応するCSS2プロパティの値と同じである。 値が1つしか指定されなかった場合、その値に必ずマッチしなければならない。 値のリストが与えられた場合、リスト中のいずれかの値にマッチすればよい。 @font-faceの中で値が省略された記述子は、各記述子定義に示す初期値を利用する。

'font-family'(記述子)
Value:  [ <family-name> | <generic-family> ] [, [<family-name> | <generic-family> ]]*
Initial:  depends on user agent
Media:  visual

定義するフォントのファミリ名を記述するための記述子。 値の取り方は'font-family'プロパティと同じである。 【訳注:後の方で例外を挙げたりするくらいなら「ただし'inherit'は除く」と書いて欲しかった、以下同じ】

'font-style'(記述子)
Value:  all | [ normal | italic | oblique ] [, [normal | italic | oblique] ]*
Initial:  all
Media:  visual

定義するフォントのスタイルを記述するための記述子。 値の取り方は'font-style'プロパティと同じである。 ただし、値をコンマで区切ってリストにしてもよい。

'font-variant'(記述子)
Value:  [normal | small-caps] [,[normal | small-caps]]*
Initial:  normal
Media:  visual

定義するフォントがスモールキャピタルであるか否かを記述するための記述子。 値の取り方は'font-variant'プロパティと同じである。 ただし、値をコンマで区切ってリストにしてもよい。

注。 「pryamoĭ」系のキリル書体をスモールキャピタルのフォントとして定義しておくと、うまい具合に欧文書体と一貫性が取れて都合がいい。 同様の理由で「kursiv」系のキリル書体を、イタリック体のフォントとして定義しておくとよいだろう。

'font-weight'(記述子)
Value:  all | [normal | bold | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900] [, [normal | bold | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900]]*
Initial:  all
Media:  visual

ファミリ内での相対的なウェイトを記述するための記述子。 値の取り方は'font-weight'プロパティと同じである。 ただし以下3点は例外:

  1. 相対キーワード(bolder、lighter)は使えない。
  2. 複数のウェイトを含むフォントを定義するため、値をコンマで区切ってリストにしてもよい。
  3. 'all'というキーワードを使っていかなるウェイトにもマッチするフォントを定義できる。 対象のフォントファイルが複数ウェイトを含んでいる場合や、ファミリ内にその書体と異なるウェイトが存在しない場合などが考えられる。
'font-stretch'(記述子)
Value:  all | [ normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded ] [, [ normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded] ]*
Initial:  normal
Media:  visual

ファミリ内での相対的な字幅を記述するための記述子。 値の取り方は'font-stretch'プロパティと同じである。 ただし以下3点は例外:

'font-size'(記述子)
Value:  all | <length> [, <length>]*
Initial:  all
Media:  visual

定義するフォントのサイズを記述するための記述子。 'font-size'プロパティとは異なり、値には絶対単位の長さしか使えない。 長さの値をコンマで区切ってリストにしてもよい。

初期値になっている'all'という値は、ほとんどのスケーラブルフォントに適していると言える。 したがって、この記述子は主にビットマップフォント、もしくはラスタライズできる範囲が限られたスケーラブルフォントの@font-face定義で利用することになる。

15.3.3 フォントデータの範囲を限定するための記述子(Descriptors for Font Data Qualification: 'unicode-range')

以下の記述子は必須ではないが、目的の文字を描画するにはグリフが不十分なフォントを、無駄に調査したりダウンロードしたりするのを回避するために利用する。

'unicode-range' (Descriptor)
Value:  <urange> [, <urange>]*
Initial:  U+0-7FFFFFFF
Media:  visual

定義するフォントが扱える文字の範囲を、ISO10646文字集合のコードで記述するための記述子。

<urange>の値は「U+」に続く16進数で表現する。 数値は[ISO10646]の文字コード位置に対応する。

たとえば「U+05D1」というのは、ISO10646文字集合ではヘブライ文字の「ベータ」を表す。 基本多言語面以外の値を用いるには、面番号を表す16進数を更に前付けしてやる。 「U+A1234」と書いて第10面のコード位置1234にあたる文字を表す、など。 基本多言語面以外の文字を使わない場合、「0000004D」などと上位桁に0を前付けしてもよいが、必ずしもそうする必要はない。

この記述子の初期値は、基本多言語面「U+0-FFFF」だけでなくISO10646文字集合全体をもカバーしている。 したがって、初期値を変更しないのならば、定義されるフォントはISO10646文字集合内の任意の文字を含んでいてよい。 逆に'unicode-range'の値を設定してやれば、UAはフォントに目的のグリフが含まれているかどうかを調べなくてもすむので、効率的な検索が可能になる。

値は何桁で書いてもよい。 「?」は1桁相当のワイルドカードであり、コード位置を領域指定する。 どう使うかというと:

unicode-range: U+20A7
ワイルドカード無し。 1文字分のコード位置を指す。 (例に挙げたのはスペインの通貨単位「ペセタ」を表す文字)
unicode-range: U+215?
ワイルドカードが1つ。 2150から215Fまで(分数)のコード領域を指す。
unicode-range: U+00??
ワイルドカードが2つ。 0000から00FFまで(Latin-1)のコード領域を指す。
unicode-range: U+E??
ワイルドカードが2つ。 0E00から0EFFまで(ラオ語の用字系)のコード領域を指す。

値の組をダッシュでつなぐと、広範のコード領域を指し示すことができる。 たとえば:

unicode-range: U+AC00-D7FF
AC00からD7FFまで(ハングル)のコード領域を指す。

値をコンマで区切れば、断続的な複数の領域を指定することもできる。 他の場所でコンマ区切りのリストを用いる場合と同様、コンマの前後に空白類文字を挿入しても無視される。 例を挙げよう:

unicode-range: U+370-3FF, U+1F??
これは0370から03FF(現代ギリシャ文字)までと、1F00から1FFF(古代ギリシャ文字)までのコード領域を指す。
unicode-range: U+3000-303F, U+3100-312F, U+32??, U+33??, U+4E00-9FFF, U+F9000-FAFF, U+FE30-FE4F
これはISO10646文字集合内から中国文字のみを抜き出した非常に大きなフォントである。 日本や韓国だけで使われる文字を含まないよう、最悪に冗長な書き方をしてみた。 3000から303Fまでは57種のCJKの記号類及び各種区切り文字。 3100から312Fまでは40種のBopomofo(注音字母とも言う、中国語音を表記するための表音文字のこと)。 3200から32FFまでは202種の囲み文字及び月表示。 3300から33FFまでは249種のCJK互換文字。 4E00から9FFFまでは20902種のCJK統合漢字。 F900からFAFFまでは302種のCJK互換漢字。 FE30からFE4Fまでは28種のCJK互換形。

ただ、典型的な中国語のフォントを記述するなら次のようにするのが普通だろう:

unicode-range: U+3000-33FF, U+4E00-9FFF

unicode-range: U+11E00-121FF
アステカ文明の象形文字用に登録が提案されている領域。 第1面の1E00から21FFまでを指す。
unicode-range: U+1A00-1A1F
古代アイルランドのオガム文字用に登録が提案されている領域。 基本多言語面の1A00から1A1Fまでを指す。

15.3.4 数値指定に基準を与えるための記述子(Descriptor for Numeric Values: 'units-per-em')

定義するフォントのem平方の長さを相対的に表す数値を記述するための記述子。 この数値は他の記述子で様々な長さを表現するのに使われる。 したがって、この値に依存する記述子を用いる場合、'units-per-em'の指定は必須である。

'units-per-em'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

この記述子によって、文字座標系、すなわちグリフがレイアウトされる格子の相対サイズを与えてやる。

15.3.5 フォントを参照するための記述子(Descriptor for Referencing: 'src')

この記述子は、フォントをダウンロードするかローカルのものを利用するかに関わらず、実際のフォントデータを参照するのに利用する。 したがって省略は許されない。

'src' (Descriptor)
Value: [ <uri> [format(<string> [, <string>]*)]? | <font-face-name> ] [, <uri> [format(<string> [, <string>]*)]? | <font-face-name> ]*
Initial: undefined
Media: visual

外部への参照もしくはローカルの書体名を、優先順にコンマで区切って記述する。 フォントをダウンロードする必要がある場合は外部への参照が必須であり、この記述子によってWeb上のフォントデータを指し示してやる。 参照先フォントは元々のフォントの一部だけを取り出したものでもよい。 たとえば、現在のページもしくは周辺の数ページを表示できる必要最小限のグリフだけを含んでいてもよい。

外部参照の値には、まず参照先フォントのURIを書き、その後にオプションとしてフォントのフォーマット情報が続くこともある。 このフォーマット情報は、クライアントが使えないフォントを無駄に取得しないようにするためのものである。 ハイパーテキストでの参照情報がいかなる場合も嘘を含み得るのと同様に、ここでも参照先には別のフォーマットのフォントが存在している可能性はある。 しかし、この情報を活用した方が、URIのファイル拡張子を解析するよりずっと信頼性のある推測が可能になるだろう。

フォーマット情報は、フォーマットを表すための決まった文字列をコンマで区切ったものである。 UAは、自身のサポートしているフォーマット名を知っていれば、使えないフォントをダウンロードしなくて済む。

本仕様で定めるフォーマット名の文字列は以下の通り。 多くのプラットフォームで実装されていそうなものを取り上げた:

文字列フォーマット一般的な拡張子
"truedoc-pfr"TrueDoc™ Portable Font Resource .pfr
"embedded-opentype"Embedded OpenType .eot
"type-1"PostScript™ Type 1 .pfb, .pfa
"truetype"TrueType .ttf
"opentype"OpenType, including TrueType Open .ttf
"truetype-gx"TrueType with GX extensions
"speedo"Speedo
"intellifont"Intellifont

URIを用いる他の一般的な場面と同様、相対URIを使ってもよい。 この場合、絶対URIへの解決は@font-faceを含んでいるスタイルシートのURIから行われる。

ローカルにあるフォントを<font-face-name>から参照するには、フォントの完全名を記してやる。 ここで、フォントの完全名とはOSから受け取る類の名称であり、ユーザやブラウザのスタイルシート、あるいはイントラネットでの共有スタイルシートなどで使われるものである。 ボールド、イタリック、下線などの装飾に関する記述は、ファミリ内で書体を区別する目的でよく名称に盛り込まれる。 フォントの完全名についての詳細はまた後で取り上げる。

<font-face-name>はフォントの完全名とし、スペースや区切り文字が入ってもいいように引用符で括らなければならない。 また、その引用文字列は更に「local(」と「)」の間に入れること。

src: url("http://foo/bar")
絶対URI。 フォントのフォーマットに関する情報は見当たらない。
src: local("BT Century 751 No. 2 Semi Bold Italic")
ローカルにインストール済みである特定のフォントへの参照。
src: url("../fonts/bar") format("truedoc-pfr")
相対URI。 指定先ではTrueDocフォーマットのフォントが手に入る。
src: url("http://cgi-bin/bar?stuff") format("opentype", "intellifont")
絶対URI。 この場合、指定先のスクリプトがOpenType、Intellifontという2種類のフォーマットでフォントを生成する。
src: local("T-26 Typeka Mix"), url("http://site/magda-extra") format("type-1")
選択肢が2つ用意されている。 1つめはローカルにインストール済みのフォントであり、2つめはダウンロード可能なType1フォーマットのフォントである。

ローカルフォントへのアクセスは完全名<font-face-name>を通じて行われる。 実際のところ、書体名というのは一意でもなければプラットフォームやフォーマットに対して独立なわけでもないのだが、ローカルにインストール済みのフォントデータを識別するのにはこれが最善の手段であろう。 加えて、グリフについて必要な補完情報を提供してやれば、書体名を利用する手段はより正確さを増すこととなる。 たとえば、そのフォントに含まれるグリフがカバーするISO10646文字コード位置の範囲などを指定するとよい。('unicode-range'を参照)

15.3.6 マッチングのための記述子(Descriptors for Matching: 'panose-1', 'stemv', 'stemh', 'slope', 'cap-height', 'x-height', 'ascent', and 'descent')

以下の記述子はCSS2の定義上オプションとなっているが、賢いマッチングやフォントサイズの調整をしたいのならばこれらを利用するとよい。

'panose-1'(記述子)
Value:  [<integer>]{10}
Initial:  0 0 0 0 0 0 0 0 0 0
Media:  visual

Panose-1マッチングシステムを利用するための記述子。 値は空白類文字で区切られた10個の10進整数から成る。 Panose-1システム自体がマッチする値の範囲を指示できるので、この記述子で値をコンマ区切りのリストにしてはならない。 初期値は「すべてゼロ」、つまり各PANOSE属性値は何でもよく、これを変更しなければあらゆるフォントにマッチする。 欧文フォントを用いる際には、Panose-1記述子の利用を強く推奨する。 詳細は附記Cを参照せよ。

'stemv'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

フォントの垂直画線幅を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'stemh'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

フォントの水平画線幅を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'slope'(記述子)
Value:  <number>
Initial:  0
Media:  visual

フォントの縦ストロークの(垂直軸に対する)角度を記述するための記述子。

'cap-height'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

大文字グリフの高さを記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'x-height'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

小文字グリフの高さを記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。 この記述子は'font-size-adjust'プロパティと併用するのが非常に有意義である。 なぜなら、候補に挙がったフォントの縦幅比を計算するには、フォントサイズとx-heightの両方が必要になるからである。 このことから、フォント記述にはこの記述子を含めるよう推奨する。

'ascent'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

アクセントを除いた状態におけるアセンダの最高点を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'descent'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

アクセントを除いた状態におけるディセンダの最低点を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

15.3.7 フォントを加工するための記述子(Descriptors for Synthesis: 'widths', 'bbox' and 'definition-src')

フォントを加工するとは、最低限指定されたフォントの横幅メトリックをマッチさせる操作である。 その目的を達成するには定義するフォントのメトリック情報を与える必要がある。 また、プログレシブ描画においても、フォントのロード時に内容の再流し込みを避けるにはメトリック情報が必須である。 以下の記述子はCSS2の定義上オプションとなっているが、文書作成者がフォント加工(あるいは上記問題を解決したプログレシブ描画)を利用したいのならばその一部は必須となる。 代替フォントは、目的のフォントが利用可能になればただちに置き換えてしまうべきである。 以下の記述子を指定しておけば、目的のフォントにできるだけ近いものを、できるだけ迅速に提供できるようになる。

以下に示す記述子のうち特に重要なのは、'widths''bbox'である。 これらは、目的のフォントが利用可能になった際、テキストの再流し込みを抑制するのに用いる。 更に、マッチングのための記述子も、フォント加工を改善するのに役立つ。

'widths'(記述子)
Value: [<urange> ]? [<number> ]+ [,[<urange> ]? [<number> ]+]*
Initial: undefined
Media: visual

グリフの幅を記述するための記述子。 <urange>に続けて1つ以上のグリフ幅を数値指定し、それをコンマ区切りのリストにしたものが値となる。 この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

<urange>を省略すると、あらゆる文字をカバーする「U+0-7FFFFFFF」という範囲が仮定される。 グリフ幅を指定する数値の個数が少なすぎる場合、最後に指定した数値が残りの全範囲をカバーする。 逆に数値をたくさん指定しすぎた場合、後方の余分な数値はすべて無視される。

例を挙げよう:

widths: U+4E00-4E1F 1736 1874 1692
widths: U+1A?? 1490, U+215? 1473 1838 1927 1684 1356 1792 
    1815 1848 1870 1492 1715 1745 1584 1992 1978 1770

前者の例だと、4E00から4E1Fまでの32文字分にグリフ幅を割り当てている。 コード番号4E00の文字はグリフ幅1736、コード番号4E01の文字はグリフ幅1874である。 ここで、数値が32文字分指定されていないので、4E02から4E1Fまでの残り30文字はすべてグリフ幅1692となる。 後者の例だと、1A00から1AFFまでの256文字にはグリフ幅1490を割り当て、2150から215Fまでの16文字には1つ1つ異なるグリフ幅を割り当てている。

この記述子は、単独の文字情報に複数のグリフが対応する場合、あるいは複数の文字情報が合字と化す場合に適切な記述が不可能である。 したがってこの記述子は、文脈に依存しない、あるいは合字が不可欠ではない用字系でのみ利用できる。 しかし、文字情報とグリフの対応が1対多・多対多にならざるを得ない用字系でも、なおこの記述子は役に立つ。 つまり、フォント加工のためにではなく、フォントのダウンロードや賢いマッチングのためになら、上記のような用字系でもこの記述子を活用することができる。

'bbox'(記述子)
Value:  <number>, <number>, <number>, <number>
Initial:  undefined
Media:  visual

フォントの境界ボックスの限界を記述するための記述子。 値には4つの数値をコンマで区切りのリストとして指定する。 これらの数値は順に、境界ボックス左下隅のx座標、同y座標、ボックス右上隅のx座標、同y座標を示している。

'definition-src'(記述子)
Value:  <uri>
Initial:  undefined
Media:  visual

フォント記述子は、スタイルシート内のフォント定義に含めてもよいし、別にフォント定義リソースを用意してそれをURIで指し示してやってもよい。 後者のやり方だと、複数のスタイルシートが同じフォントを参照する場合にネットワーク・トラフィックを削減することができる。

15.3.8 位置合わせのための記述子(Descriptors for Alignment: 'baseline', 'centerline', 'mathline', and 'topline')

以下の記述子はオプションであり、異なる用字系の文字列を揃えるのに利用する。

'baseline'(記述子)
Value:  <number>
Initial:  0
Media:  visual

フォントの下ベースラインの位置を記述するための記述子。 この記述子がデフォルト以外の値(ゼロ以外の値)を取る場合は、'units-per-em'も同時に指定しなければならない。

'centerline'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

フォントの中央ベースラインを記述するための記述子。 値が未定義のままなら、全グリフの最上部と最深部の間を取るなど適当な決め方をしてしまってもよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'mathline'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

フォントの数学記号のベースラインを記述するための記述子。 値が未定義である場合、中央ベースラインをそのまま流用するとよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

'topline'(記述子)
Value:  <number>
Initial:  undefined
Media:  visual

フォントの上ベースラインを記述するための記述子。 値が未定義のままなら'ascent'の値を流用してもよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。

15.3.9 フォント記述の例(Examples)

以下のようなフォントが与えられたとする:

Swiss 721 light light & light italic
Swiss 721 roman, bold, italic, bold italic
Swiss 721 medium medium & medium italic
Swiss 721 heavy heavy & heavy italic
Swiss 721 black black, black italic, & black #2
Swiss 721 Condensed roman, bold, italic, bold italic
Swiss 721 Expanded roman, bold, italic, bold italic

これらをダウンロードして使えるようにするには、たとえば記述子を以下のようにする:

@font-face {
    font-family: "Swiss 721";
    src: url("swiss721lt.pfr"); /* Swiss 721 light */
    font-style: normal, italic;
    font-weight: 200;
}
@font-face {
    font-family: "Swiss 721";
    src: url("swiss721.pfr"); /* The regular Swiss 721 */
}
@font-face {
    font-family: "Swiss 721";
    src: url("swiss721md.pfr"); /* Swiss 721 medium */
    font-style: normal, italic;
    font-weight: 500;
}
@font-face {
    font-family: "Swiss 721";
    src: url("swiss721hvy.pfr"); /* Swiss 721 heavy */
    font-style: normal, italic;
    font-weight: 700;
}
@font-face {
    font-family: "Swiss 721";
    src: url("swiss721blk.pfr"); /* Swiss 721 black */
    font-style: normal, italic;
    font-weight: 800,900; /* note the interesting problem that
                               the 900 weight italic doesn't exist */
}
@font-face {
    font-family: "Swiss 721";
    src: url(swiss721.pfr); /* The condensed Swiss 721 */
    font-stretch: condensed;
}
@font-face {
    font-family: "Swiss 721";
    src: url(swiss721.pfr); /* The expanded Swiss 721 */
    font-stretch: expanded;
}

15.4 フォントの特性(Font Characteristics)

15.4.1 概要(Introducing Font Characteristics)

この章では、クライアント側でフォントのマッチング・加工を行う場合や、Webにアクセスして異なるプラットフォームからフォントをダウンロードする場合などに役立つとされている、フォントの特性を列挙する。 フォントデータを物理的に埋め込む以外の用途で、Web上のフォントを使う必要がある媒体にとっても、これら特性に関する情報は役に立つことだろう。

以下に解説する特性は、フォントを特徴付けるのに用いられており、CSSやスタイルシートの分野に特有な概念ではない。 CSSではたまたまこれらの特性を記述するのにフォント記述子を利用しているが、VRMLのノード、CGMのアプリケーション構造、Java API、CSS以外のスタイルシート言語など、別の表現形式への写像も可能であろう。 フォントの特性を取り扱うのに共通の汎用システムを利用している場合、ある媒体で1度利用したフォントをプロキシにキャッシュして別の媒体で再利用すれば、ダウンロード時間やネットワークのバンド幅を節約することができる。

そのような利用法が可能な媒体を一部列挙しておこう:

15.4.2 フォントの完全名(Full font name)

ファミリ内の特定の1書体を識別する完全な名前のこと。 普通は、ファミリ名にテキストの特徴に関する様々な修飾語句(特に規則性はない)を付けて完全名とする。 完全名には(多くの場合ファミリ名に続けて)ベンダの名称やその短縮形が含まれることもある。 修飾語句の付け方がプラットフォームによって様々なので、完全名はローカルフォントを参照する場合にのみ用いられる。 また、完全名は必ず引用符で括らねばならない。

完全名の差異については、たとえばTrueTypeのファミリ名とPostScriptのそれとでは、スペースや区切り文字の使い方が異なったりする。 あるいは、システムやプリンタ・インタプリタの都合で名前の長さに制限があると、ある種の単語では短縮形に相違を生じる場合がある。 たとえば、完全名ではごく一般的に使われているスペース文字、これをPostScriptファミリ名に含ませることはできない。 一方、TrueTypeファミリ名には、PostScriptのようにスペース文字が入らない名前も使用可能である。

フォント定義に用いる名前は、あらゆるローカルフォントに対するエイリアスになり得るという意味において非常に重要である。 つまり、プラットフォームやアプリケーションから独立した強力な名前を採用することが肝心であり、特定のアプリケーション、自然言語に依存した名前は避けるべきである。

理想的にはフォントデータの集合を各々一意に識別できるような名前があれば良いのだが、現状ではそうもいかない。 同じ書体名のフォントでも記述子の値はそれぞれである。 カバーするグリフの範囲が違うといった程度なら必要なグリフさえ手に入れば関係ないのでそれほど深刻でもないが、メトリック情報に差異があったりすると、同名のフォントなのに中身は非互換という不都合な事態を招いてしまう。 しかし、この非互換性を常に識別可能にし、なおかつ正しいローカルデータの利用を誤って妨げずにすむような規則はとても定義できそうにない。 したがって、現状で書体名のマッチングを判定するのには、ISO10646文字集合のコード情報だけを頼りにすることとなるだろう。

フォント定義に書体名を記述する主目的は、指定されたフォントデータがローカルに存在する可能性を考慮して、UAが適切な判断を下せるようにしておくことである。 したがって、フォントデータの完全な複製があるならば両者は同じ書体名でなければならない。 さもなくば、マッチングするはずだったローカルフォントを見落として、不必要にWebトラフィックを増大させてしまうだろう。

15.4.3 文字座標系(Coordinate units on the em square)

幅メトリックなどある種の値では、同種同サイズフォントのベースライン間距離を一辺とする、架空の正方形に対する相対値でもって長さを表現する。 この正方形のことをem平方と呼び、グリフのアウトラインを定める際にもこのグリッドが設計枠となる。 この記述子では、em平方が何単位に分割されているかを指定する。 たとえば、Intellifontの値が250、Type 1の値が1000、TrueType、TrueType GX、OpenTypeなどの値が2048、この辺りが一般的だろう。

この値が未指定だと、いかなるフォントメトリック情報も無意味になってしまう。 たとえば、あるフォントでは小文字の高さが450なのに、それより小さいはずの別のフォントでは同890だ、というおかしなことになる。 実際には、前者を450/1000、後者を890/2048というように分数として捉えてやれば、後者の方が小さい値になる。

15.4.4 中央ベースライン(Central Baseline)

em平方内における、中央ベースラインの位置を与える。 中央ベースラインは、表意文字の位置揃えに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。

15.4.5 フォント符号化(Font Encoding)

陰にも陽にも、各フォントはそれぞれにフォント符号化表を有しており、そこにはグリフと文字情報の対応関係が収めらている。 また、この表は符号化ベクトルとも呼ばれる。

実際、1つの文字情報に複数のグリフが対応するようなフォントは数多く存在している。 こういったフォントでは、言語特有の規則や文書設計者の意図に応じてグリフを使い分ける。

たとえばアラビア語の場合、すべての文字について4種類(もしくは2種類)の形状が存在する。 そして、その文字が文頭にくるか、文末にくるか、文中にくるか、単独で出現するかによって4者を使い分けるのである。 しかし、いずれのグリフを使う場合にも文字情報は同じであり、ソース文書内での表現は1種類のみである。 印刷した時点で【訳注:もしくは相応の機能を備えたビューアで表示した時点で】、初めて各々が異なる見え方にあんるのである。

また、グリフの形状選択作業を文書設計者に任せるフォントも存在する。 しかし残念ながら、CSS2ではまだこの選択手段を提供することはできない。 現状では、フォント側で勝手に選ぶ形状が常にデフォルトとなる。

15.4.6 フォントファミリ名(Font family name)

書体名からファミリの部分を取り出したものを指定する。 たとえば、Helvetica-Boldのファミリ名はHelveticaだし、ITC Stone Serif Semibold Italicのファミリ名はITC Stone Serifである。 システムによっては、字幅に関する修飾語句をファミリ名の一部にしてしまう場合もある。

15.4.7 グリフの幅(Glyph widths)

フォントの設計枠(em平方)上におけるグリフの幅を、各文字情報ごとに記したリスト。 ISO10646のコード順に記す。 1つの文字情報が複数のグリフに対応する場合や、合字を使わざるを得ない場合、それら特殊なグリフに対して幅を指定することはできない。

15.4.8 水平画線幅(Horizontal stem width)

フォントの中核となる水平画線についての記述。 フォントを設計する上では複数の画線幅を使い分けるのが普通である。 たとえば、ローマン体の文字で中核となっている垂直画線はセリフ体の「M」や「N」などの文字に見られる細い画線とは大分違うものであるし、同じフォントでも大文字と小文字で画線幅が異なっていたりする。 また、設計上の理由にせよ手違いにせよ、画線幅というものはすべて微妙に異なっていそうなものである。

15.4.9 大文字グリフの高さ(Height of uppercase glyphs)

ラテン、ギリシャ、キリルなどの用字系における、ベースラインから大文字上端までの寸法。 この記述子は、これらの用字系に属するグリフをまったく含まないフォントに対しては、必ずしも役に立つとは限らない。

15.4.10 小文字グリフの高さ(Height of lowercase glyphs)

ラテン、ギリシャ、キリルなどの用字系における、ベースラインから小文字上端(アクセントやアセンダは除く)までの寸法。 これは上端が平らな文字についての話であり、いかなる余計な微調整領域も無視される。 この値は、フォントファミリを比較する手段として、大文字と小文字の高さの比を求めるのに用いられる。

x-heightの説明図

この記述子は、上出の用字系に属するグリフをまったく含まないフォントに対しては役に立たない。 大文字と小文字の高さは、フォントの比較を行うために両者の割合という形で表現されることが多い。 したがって、ヘブライ語などのように活字ケースが1種類のみの用字系においても、大文字と小文字の高さに両方同じ値を設定しておくのはそれなりに意味のあることかもしれない。 すなわち、ラテンとヘブライの用字系が混在するテキストなどで、ヘブライ文字の高さが(ラテンフォントの)大文字と小文字の間の高さになってくれるのである。

ヘブライ文字の高さ

15.4.11 下ベースライン(Lower Baseline)

em平方内における、下ベースラインの位置を与える。 下ベースラインは、ラテン、ギリシャ、キリルなどの用字系において位置揃えに用いられる。 サンスクリット起源の用字系における上ベースラインと同じ役割を果たす。

15.4.12 数学記号のベースライン(Mathematical Baseline)

em平方内における、数学記号のベースラインの位置を与える。 これは数学記号の位置を揃えるのに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。

15.4.13 境界ボックスの限界(Maximal bounding box)

仮にフォントに含まれる全グリフを同じ位置に置いて描画した時、その結果できあがった形状を囲い込める最小の矩形のこと。

あるフォントの部分集合を取り出して、別のフォントとしてダウンロード可能にする場合、その境界ボックスは元々のフォントに合わせるべきである。

15.4.14 アクセントを除いた状態におけるグリフの最高点(Maximum unaccented height)

em平方内における、ベースラインからグリフ最高点(アクセントや発音区別符号は除く)までの寸法。

アクセントを除いた状態におけるグリフの最高点

15.4.15 アクセントを除いた状態におけるグリフの最低点(Maximum unaccented depth)

em平方内における、ベースラインからグリフ最低点(アクセントや発音区別符号は除く)までの寸法。

アクセントを除いた状態におけるグリフの最深部

15.4.16 Panose-1属性値

Panose-1とは、TrueTypeの分類及びマッチング技術の工業標準である。 PANOSEシステムは10種類の数値指定から成り、それらの数値は、ラテン書体の主要な特徴を表すもの、これらの数値を意味付けするための分類手続きを行うもの、与えられた書体の集合からもっとも可能性のあるマッチングを決定するマッピングソフトウェアを表すもの、などに大別される。 このシステムは、修正すればおそらくギリシャやキリル書体にも適用可能だろうが、活字ケースが1種類のみの用字系や表意文字(ヘブライ、アルメニア、アラビア、日中韓などの文字)にはあまり向いていない。

15.4.17 ISO10646文字集合におけるグリフの範囲(Range of ISO 10646 characters)

ISO10646(Unicode)における、フォントが含んでいるグリフの範囲。 単独のフォントが含んでいるグリフはごく僅かなので(大半のフォントはISO10646の全範囲をカバーしていない)、この記述子を用いてカバーしているグリフが含まれるブロックや領域を列挙してやる(指定した領域を完全にカバーできるとは保証しない)。 これによって、不適切なフォント(必要なグリフを持っていないフォント)を候補から外すことができる。 この記述子による範囲指定は、フォントから必要なグリフを得られると断定しているわけではなく「試しにダウンロードしてみる価値はある」という程度の意味しか持たない。 詳細情報を得るための有用な文書群については[ISO10646]を参照せよ。

この方法は、構文を変更したり既存文書の内容に何ら不都合をきたすことなく、将来のUnicode文字の割り付け方法に対して拡張可能である。

グリフの範囲についての情報を含み得ないフォントフォーマットでは、陰にあるいは陽にこの特性を利用することとなるだろうが、その値は文書作成者もしくはスタイルシート設計者が与えなければならない。

この他にも用字系の分類方法としてはMonotype system([MONOTYPE]を参照)やISO script systemなどが存在するが、これらは容易に拡張可能ではない。

こういった理由から、本仕様ではフォントごとに正確な分類が可能なISO10646の領域指定によるグリフ分類方法が採用されている。 この方法だと、将来文字の割り付け方がどのように変更されても柔軟に対応可能である。

15.4.18 上ベースライン

em平方内における、上ベースラインの位置を与える。 上ベースラインは、サンスクリットを起源とする用字系の位置揃えに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。

15.4.19 垂直画線幅(Vertical stem width)

グリフの垂直画線(もしくはほぼ垂直に近い画線)幅についての記述。 ヒンティングと密接な関わりを持つことが多く、いくつかのフォントフォーマットではこの情報を直接抽出することができない。 垂直画線と一言でいっても数種類に(たとえば、通常幅の画線、大文字のMやNなどに用いる軽いウェイトの画線、などのように)分類されるのが普通なので、この値としてはフォントの中核となる垂直画線の寸法を扱うこと。

15.4.20 垂直画線の傾き(Vertical stroke angle)

フォントの中核となる垂直画線の(垂直軸に対する)傾きを反時計回りに度単位で測ったもの。 大半のイタリック体フォントのように右に傾いている場合は負の値をとる。 この記述子は、オブリーク体、スラント体、筆記体など、垂直画線が正確に垂直ではないようなフォント一般に対しても指定してよい。 すなわち、この値が非ゼロだからといって、直ちにそのフォントがイタリック体と断定できるわけではない。

15.5 フォントのマッチングアルゴリズム(Font matching algorithm)

本仕様ではCSS1で示したマッチングアルゴリズムを拡張する。 ただし、文書作成者やユーザのスタイルシートに@font-faceが存在しない場合には、CSS1のアルゴリズムをそのまま利用する。

記述子と書体のマッチングは慎重に行わなければならない。 マッチング処理の結果がUAに関わらず等しくなるように(もちろんこの場合、システムに存在する書体とそれに対応するフォント記述がまったく同じであるという前提付きだが)、記述子を処理する順序を決めておくことにする。 実装が吐き出す結果さえ正しければ、このアルゴリズムはどのように最適化してもよい。

  1. UAが認識できる総てのフォントについて、関係する書体記述子のデータベースを作成する。 記述子の値がまったく等しいエントリが2つある場合は片方を無視すること。 UAが認識できているフォントとは、以下のようなものを言う:
  2. 当該要素及びそこに含まれる各文字について、適用可能なフォント関連プロパティとその値をすべて調査する。 これら様々なプロパティを活用するにあたって、UAはまず'font-family'記述子を見て仮の一時ファミリを決定する。 つまり、他の記述子を調べるに先立って、とりあえずファミリ名のマッチングを成功させる。 残りのプロパティについても各記述子の基準に従ってマッチングを試み、すべてのプロパティにマッチする@font-faceが存在すれば、その書体を当該要素に適用する。
  3. 手順2の作業で候補に挙がった一時ファミリの中にマッチする書体が見つからなかった場合、賢いマッチングを実装しているUAは、'x-height'、'widths'、'panose-1'などの記述子を駆使して、別の一時ファミリを選びにかかってよい。 こうして選んだ@font-faceのうち、残りすべての記述子についてマッチするものがあれば、その書体を当該要素に適用する。 この時、賢いマッチングによって要求(プロパティ)とは異なるファミリの書体が選択されたとしても、CSS2プロパティの側では、初めに要求したファミリがマッチングに成功したものとみなす。 賢いマッチングを実装していないUAはこの手順を失敗したとみなす。
  4. 手順3の作業で候補に挙がった一時ファミリの中にマッチする書体が見つからなかった場合、フォントのダウンロードを実装しているUAは、手順2もしくは3で候補に挙がった@font-faceの'src'記述子を見て、そのリソースが利用可能かどうかを(フォントフォーマットも含めて)調査する。 こうして選んだ@font-faceのうち残りすべての記述子についてマッチするものがあれば、それは当該要素にマッチする書体であり、リソースのダウンロードに取り掛かってよい。 UAはこのダウンロードを途中で中止しても、ダウンロードが終わる前に次の手順を始めてしまってもよい。 フォントのダウンロードを実装していない、ネットワークに接続していない、ユーザ設定でこの機能が使えなくなっている、要求されたリソースが何らかの理由で取得不可能である、取得したフォントが何らかの理由で使えない、などの事情がある場合、この手順は失敗したものとみなす。
  5. 手順3の作業で候補に挙がった一時ファミリの中にマッチする書体が見つからなかった場合、フォントの加工を実装しているUAは、'x-height'widths'panose-1'などの記述子を調べて加工に適した別の一時ファミリを選びにかかってよい。 こうして選んだ@font-faceのうち残りすべての記述子についてマッチするものがあれば、それは当該要素にマッチする書体であり、フォントの加工に取り掛かってよい。 フォントの加工を実装していないUAはこの手順を失敗したものとみなす。
  6. 手順3から5がすべて失敗した場合、フォントセットに次のファミリ候補があれば、そのファミリについて手順2からの作業を繰り返す。
  7. マッチする書体が見つかったにも拘らずその書体が目的のグリフを含んでいない場合、フォントセットに次のファミリ候補があれば、そのファミリについて手順2からの作業を繰り返す。 なお、目的のグリフが得られない書体をさっさと候補から外したいなら'unicode-range'も活用するとよい。 'unicode-range'の示す範囲内に目的のグリフが含まれていれば、UAにとってグリフの存在を確認してみる価値があるということだ。
  8. 手順2でフォントセットの選択肢が底をついた場合、親要素からの継承値もしくはUAのデフォルト('font-family'の初期値)を一時ファミリとして手順2からの作業を繰り返し、もっとも上手くマッチするものを採用する。 ここまでしてなお適切に表示できない文字がある場合、UAは表示不可能だということがはっきり判るように(たとえば、そういう意味を持った専用のグリフを使うなどして)明示すべきである。
  9. プログレシブ描画を実装していてフォントをダウンロード中のUAは、ダウンロードが無事完了し次第そのフォントを使い始めるとよい。 この時、ダウンロードしたフォントが必要なグリフをいくつか欠いていて、プログレシブ描画に使ったフォントからそのグリフを調達できる場合、必要な部分だけ置き換え前のグリフを使い続ける。

注。 以上に示したアルゴリズムは、各文字ごとにプロパティ調査をするといった面倒な事態を避けるために最適化してよい。

手順2における記述子ごとのマッチング規則は以下の通り:

  1. まずは'font-style'のマッチングを試みる。 'italic'という値は、フォントデータベースで'italic'もしくは'oblique'に分類されている書体にマッチする('italic'の方が好ましい)。 上記以外の場合、プロパティの値と分類名が正確にマッチしなければならない。 さもなくば失敗である。
  2. 次に'font-variant'である。 'normal'という値は、データベースで'small-caps'と分類されていない書体にマッチする 'small-caps'という値は以下のいずれかを満たす書体にマッチする。 スモールキャピタルのフォントは、通常フォントの大文字を機械的に縮小して作り出してもよい。
  3. 次に'font-weight'をマッチさせる。 これは必ず成功する。(次章を参照せよ)
  4. 'font-size'についてもUAごとの許容範囲内にマッチしなければならない(通常スケーラブルフォントのサイズは要求にもっとも近いピクセル値に丸められる。 一方ビットマップフォントの場合は最悪でも上下20%までが許容範囲だろう)。 なお、他の計算(たとえば相対単位emの解決など)でフォントサイズを利用する場合は、'font-size'の指定値ではなく実際に使われる値を基準に計算すること。

15.5.1 数値とウェイト名を対応付ける(Mapping font weight values to font names)

'font-weight'の値は、'400'(もしくは'normal')をファミリ内の通常ウェイトとしたときの比較値として与えられる。 '400'に対応する典型的なウェイト名にはBookRegularRomanNormal、そして稀にMediumなどがある。

上記以外のウェイトと数値との対応関係は、同一ファミリ内において順序関係を保つことのみを意図している。 UAは視覚的な順序関係が崩れないように名前と数値を対応させなければならない。 すなわち、ある数値に対応する書体が、自身より小さな値に対応する書体に比べて軽いものであってはならない。 UAが書体と数値をどう対応付けるかについては何の保証もない。 ただ、典型的なものとしては以下に示すような方法がある:

'font-weight'の各値について、それより重い書体の存在するなどということは保証しない。 たとえば、通常体とボールド体だけしかないファミリもあれば、ウェイトが8種類にものぼるファミリも存在するのである。

ありがちな対応関係の例を以下に示す。

「Rattlesnake」というファミリに4種類のウェイトがあるとしよう。 軽い方から順にRegularMediumBoldHeavyとすると対応は以下のようになる:

ウェイトの対応例・その1
書体割り当て空きの埋め方
"Rattlesnake Regular" 400 100, 200, 300
"Rattlesnake Medium" 500  
"Rattlesnake Bold" 700 600
"Rattlesnake Heavy" 800 900

「Ice Prawn」というファミリに6種類のウェイトがあるとしよう。 軽い方から順にBookMediumBoldHeavyBlackExtraBlackとすると対応は以下のようになる。 この例では、UAが「Ice Prawn ExtraBlack」という書体に数値を割り当てていないことに注意すること。

ウェイトの対応例・その2
書体割り当て空きの埋め方
"Ice Prawn Book" 400 100, 200, 300
"Ice Prawn Medium" 500  
"Ice Prawn Bold" 700 600
"Ice Prawn Heavy" 800  
"Ice Prawn Black" 900  
"Ice Prawn ExtraBlack" (none)  

15.5.2 マッチングの例(Examples of font matching)

以下の例ではAlabama Italicという書体を定義している。 PANOSE属性値とTrueTypeフォントの検索先URI、それにウェイトやスタイルを記述した記述子も与えられている。 この宣言によると、ウェイトは要求が300、400、500の場合にマッチすることになる。 また、ファミリ名はAlabama、修飾名(完全名)はAlabama Italicとなっている。

@font-face {
  src: local("Alabama Italic"),
       url(http://www.fonts.org/A/alabama-italic) format("truetype");
  panose-1: 2 4 5 2 5 4 5 9 3 3;
  font-family: Alabama, serif;
  font-weight:   300, 400, 500;
  font-style:  italic, oblique;
}

次の例では1つのファミリを定義している。 フォントデータ検索のために与えられたURIはただ1つだが、このデータファイルには様々なスタイル及びウェイトのグリフが含まれていると思われる。 どちらか一方の@font-faceがひとたびデリファレンスされれば、そのデータはキャッシュに蓄積されて、同じURIの別書体に使い回しできる。

@font-face {
  src: local("Helvetica Medium"),
       url(http://www.fonts.org/sans/Helvetica_family) format("truedoc");
  font-family: "Helvetica";
  font-style: normal
}
@font-face {
  src: local("Helvetica Oblique"),
       url("http://www.fonts.org/sans/Helvetica_family") format("truedoc");
  font-family: "Helvetica";
  font-style: oblique;
  slope: -18
}

次の例では、本来別物である3つのフォントを1つにまとめて、多くのグリフをカバーできる仮想フォントを作り出している。 各定義の'src'記述子には完全名を与えてあるので、ローカルにインストール済みの版が利用可能ならばそちらが優先的に使われることとなる。 最後の@font-faceは前3つとグリフの範囲が重複しているが、1箇所のリソースにすべてが含まれている。

@font-face {
  font-family: Excelsior;
  src: local("Excelsior Roman"), url("http://site/er") format("intellifont");
  unicode-range: U+??; /* Latin-1 */
}
@font-face {
  font-family: Excelsior;
  src: local("Excelsior EastA Roman"), url("http://site/ear") format("intellifont");
  unicode-range: U+100-220; /* Latin Extended A and B */
}
@font-face {
  font-family: Excelsior;
  src: local("Excelsior Cyrillic Upright"), url("http://site/ecr") format("intellifont");
  unicode-range: U+4??; /* Cyrillic */
}
@font-face {
  font-family: Excelsior;
  src: url("http://site/excels") format("truedoc");
  unicode-range: U+??,U+100-220,U+4??;
}

次の例はUAのデフォルトスタイルシートにあると想像される記述である。 CSS2の総称ファミリserifを様々なプラットフォームで使われていそうなserif系フォントに対応付けている。 選択肢が非常に多いのでメトリック情報は与えられていない。

@font-face {
  src: local("Palatino"),
	  local("Times New Roman"),
	  local("New York"),
	  local("Utopia"),
	  url("http://somewhere/free/font");
  font-family: serif;
  font-weight: 100, 200, 300, 400, 500;
  font-style: normal;
  font-variant: normal;
  font-size: all
}


Last modified January 8, 1999.
Translated by Kazuteru OKAHASHI.
mailto:okahashi@nets.ne.jp