目次
文書のテキストを視覚的に表示する時、文字情報(抽象的な情報単位)を抽象グリフ(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、ウィンドウシステム、クライアントなど、様々な要因に依存するからである。
CSSフォントモデルの前半は、UAに使って欲しいフォントを指定する方法についてである。 まず第1に、フォントを名前で指定するのが明確な方法であるように思える。 ここで名前というのは一連の文字列であるが、その文字列は(様々な特徴を表す)複数のパートに分かれているのが普通である。 たとえば「BT Swiss 721 Heavy Italic」など。
残念なことに、名前に基づいたフォントの分類には、広く普及した明確な方法が存在しない。 あるフォントファミリで使われている術語が、別のファミリでは通用しないことがある。 たとえば「italic」という術語は斜体字を表すのに用いるが、斜体字を表す術語には他にもOblique、Slanted、Incline、Cursive、Kursivなどがある。 同様に、フォントの名前はウェイトを表す術語を含んでいるのが普通であるが、こういった術語の主な役割は、単独のファミリ内で異なる重みの書体を区別することである。 したがって、ウェイトの呼び名には一貫した体系が存在せず、ある単独の術語でもその使用法は多岐に亘っている。 たとえば、あるファミリで「通常」とされている重みによっては、Regular、Roman、Book、Medium、Semi-Bold、Demi-Bold、Bold、Blackなど様々な術語がボールド体を表し得る。
こういった名前体系の欠陥のせいで、ある1点のみの相違(より太く、など)を強調するための汎用的な書体名が使えなくなっている。
以上の理由から、CSSでは別のモデルを採用する。 このモデルでは、単独のフォント名ではなく、フォントに関する一連のプロパティを通してフォントを要求する。 これらのプロパティに指定された値が、フォントを選択する際の基準を形成するのである。 フォントのプロパティは「より太く」のように個別に変更することが可能であり、変更した値はデータベースから再度フォントを選択する際に活用される。 こうすればスタイルシート設計者や実装者にとって納得行く結果が得られるだろう。
CSS2では以下の特徴に基づいてフォントを指定する:
'font-size'以外のプロパティでは、相対単位emとexは当該要素の文字サイズを参照する。 一方、'font-size'では親要素の文字サイズを参照する。 詳細は[4.3.2 長さ]を参照のこと。
CSSのフォントプロパティは、テキストに適用して欲しい外観を記述するのに用いる。 一方フォント記述子は、その要求を満たす適切なフォントが選択できるように、利用可能なフォントの特徴を記述するために用いる。 フォントの特徴分類に関してはフォント記述子を参照されたい。
| 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種類の名前がある:
文書作成者には、最後の強力な選択肢として、総称ファミリ名を指定するよう推奨する。
例を挙げておこう:
<!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 }
こうすれば、各要素の言語 -- 日本語と中国語 -- に応じて適切なフォントを要求できる。
| Value: | normal | italic | oblique | inherit |
|---|---|
| Initial: | normal |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
このプロパティは、フォントファミリの中から通常体(romanとかuprightなどと呼ばれることもある)、イタリック体、斜体のいずれかを要求する。 各値は以下の様な意味を持つ:
次の例では、H1、H2、H3要素のテキストが斜体字で表示される。 ただし、H1要素内の強調テキストだけは通常体で表示される。
H1, H2, H3 { font-style: italic }
H1 EM { font-style: normal }
| Value: | normal | small-caps | inherit |
|---|---|
| Initial: | normal |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
スモールキャピタルのフォントは、小文字のグリフとして縦幅比のやや異なる小さな大文字を用いる。 このプロパティは、活字ケースが2種類存在する用字系(たとえばアルファベットには大文字と小文字がある)に対してスモールキャピタルのフォントを要求する。 ただし、活字ケースが1種類のみの用字系(こういった用字系は世界中に多く存在する)に対しては視覚効果がない。 各値は以下の様な意味を持つ:
Example(s):
次の例では、H3要素をスモールキャピタルで表示し、強調語は更に斜体で表示する:
H3 { font-variant: small-caps }
EM { font-style: oblique }
全テキストを大文字に変換するという効果に限定すれば、'text-transform'で同じ効果を得られる。
| 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 |
このプロパティは希望するウェイトのフォントを要求する。 各値は以下の様な意味を持つ:
P { font-weight: normal } /* 400 */
H1 { font-weight: 700 } /* bold */
BODY { font-weight: 400 }
STRONG { font-weight: bolder } /* 500 if available */
子供要素はウェイトの算出値(すなわち数値)を継承する。
| 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 |
このプロパティは、フォントファミリの中から希望する字幅のフォントを要求する。 絶対キーワードは、字幅の狭い方から以下の様に順序付けされる:
相対キーワード'wider'は、継承値より1段階広い字幅の値を設定する。 ただし、継承値が'ultra-expanded'である場合は変更しない。 相対キーワード'narrower'は、継承値より1段階狭い字幅の値を設定する。 ただし、継承値が'ultra-condensed'である場合は変更しない。
| 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 |
このプロパティは、行間を詰めてみた時のベースライン間距離としてフォントサイズを指定する。 各値は以下の様な意味を持つ:
[ xx-small | x-small | small | medium | large | x-large | xx-large ]
隣接するキーワードの、コンピュータ画面上における推奨スケーリング係数は1.2である。 たとえば、'medium'が12ptに対応するなら'large'は14.4ptである。 媒体が変わればスケーリング係数を変更してもよい。 また、UAはフォントサイズ対照表を計算する際、そのサイズでフォントの質が極端に悪くならないか、そのサイズに該当するフォントが存在するのか、などを考慮すべきである。 つまりフォントファミリごとに別々の対照表を準備してよい。
注。 CSS1では隣接キーワードの推奨スケーリング係数は1.5だったが、ユーザの経験からこの値は大きすぎることが判明した。
[ larger | smaller ]
たとえば親要素のフォントサイズが'medium'だとすると、'larger'は'large'と解釈される。 親要素の値が対照表にある値とかけ離れている場合、対照表に新規の値を挿入するも、もっとも近い値へ丸めてしまうもUAの自由である。 場合によっては、対照表の最も外側に新規の値を挿入するはめになるだろう。
'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 }
| 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を、代替フォントでも維持し続けることができる。 各値は以下の様な意味を持つ:
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)にラスタライズしたものである。 縦幅比も併記した。 実際は総て同じサイズであるにも拘わらず、縦幅比が大きいほど文字が大きく見えていることと思う。 このフォントサイズだと、縦幅比が極端に小さい書体は非常に読みにくい。
次の画像は、Verdanaを最初の選択肢とした時の、'font-size-adjust'による調整結果である。 併記した数字は拡大倍率である。 調整のおかげでどの書体も殆ど同じ大きさに見えるかもしれないが、これでも実際のフォントサイズには2倍以上の差がある。 また、この調整法を用いることによって、行の長さもうまく調整されることが見て取れるだろう。
| 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'と指定している。
以下の値によってシステムフォントも活用できる:
システムフォント値は、ファミリ、サイズ、ウェイト、スタイルなど全体の値を同時に設定する。 必要ならば個々の値を上書き変更することも可能である。 指定されたシステムリソースにフォントが存在しないプラットフォームでは、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
}
総称ファミリはいざという時の最終選択肢であり、指定したフォントが選択不可能な場合に、スタイル設計者の意図を最低限反映するための仕組みである。 これは予備手段なので、最適な体裁効果を得るための具体的なフォント名はやはり指定しておくべきである。
あらゆるCSSの実装系には5つの総称ファミリが定義されている(とは言っても、各総称ファミリに必ずしも別々のフォントを対応させる必要はない)。 総称ファミリに対応させるフォントについては、UAの依存環境が許す範囲内で各総称ファミリの特徴をできるだけ反映したものをデフォルトにすべきである。 【訳注:正確には「あらゆる実装系」ではなく「あらゆる視覚実装系」かと思いますが。】
UAは各総称ファミリに対応するフォントをユーザ側で変更可能にしておくよう推奨する。
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 |
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 |
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 |
CSSで言うfantasy系のフォントとは、装飾がメインになっているものの文字の表現を失ってはいないフォントを指す。 文字を表現しない絵と記号「だけ」のフォントとは異なる。 例を挙げると:
| 欧文 | Alpha Geometrique, Critter, Cottonwood, FB Reactor, Studz |
monospace系フォントであるための唯一の必要条件は、全グリフが同じ固定幅を有するということだけである(アラビア文字などの筆記体フォントにとっては妙なことになるが)。 手作業でタイプライタを打つのと似た雰囲気が得られ、コンピュータコードのサンプルを添える場合などに用いられることが多い。
この定義にあてはまるフォントには、たとえば以下のものがある:
| 欧文 | Courier, MS Courier New, Prestige, Everson Mono |
| ギリシア文字 | MS Courier New, Everson Mono |
| キリル文字 | ER Kurier, Everson Mono |
| 日本語 | Osaka Monospaced |
| チェルキ− | Everson Mono |
CSSフォントモデルの後半は、文書作成者の指定や現環境での利用可能フォント、それにその他様々な諸条件に基づいて、実際に利用するフォントをUAが選択する仕組みについてである。 フォントのマッチングアルゴリズムについての詳細は別の節で述べる。
フォントの選択には4通りの動作がある。 名前によるマッチング、賢いマッチング、フォントの加工、それにダウンロードである。
プログレシブ描画(progressive rendering)とは、フォントのダウンロードと、それ以外の手段との組み合わせである。 最初は一時的に(名前によるマッチング、賢いマッチング、フォント加工のうちいずれかを活用して選択した)代用のフォントで文字を表示し、要求されたフォントのダウンロードが完了するまでの間、ユーザが内容を読めるようにしておくのである。 目的のフォントが無事ダウンロードできれば、代用のフォントを取り除いて(できれば文書を流し込みなおさずに)置換する。
注 - プログレシブ描画で実際に利用するフォントをロードする際、内容の再レイアウトを避けるためには(実際に利用する)フォントのメトリック情報が必要になる。 このメトリック情報は多すぎると却って厄介なので、1つのフォントに対する指定は文書内で1度限りにすべきである。
フォント記述の役割は、文書作成者の指定とフォントデータを仲介することである。 フォントデータとは、テキストを整形したり、文字情報に対応させた抽象グリフを描画したりするのに必要なデータ(実際のスケーラブルなアウトライン、ビットマップ情報)のことである。 そうして定義を記述したフォントは、スタイルシートのプロパティによって参照する。
フォント記述は例のデータベースに付け加えられ、関連するフォントデータを選択する際に活用される。 フォント記述には様々な記述子が含まれ、Web上でのフォントデータのありかだとか、そのフォントデータの特色などを示している。 また、フォントのプロパティを特定のフォントデータに結び付ける際にも記述子が必要になる。 記述の詳細度については、フォントの名称を与えるだけでもよいし、グリフ幅の一覧を掲げてもよい。
フォント記述子は以下の 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で、フォントの代用、マッチング、加工などを改善するために新たな記述子が加わるかもしれないからである。
以下の記述子は各々フォントのプロパティと同じ名称になっており、単独の値、もしくはコンマで区切った値のリストを取る。
このリストに含まれる記述子の値【訳注:もちろんリストの要素が1つだけの場合も含む】は、特に注記しない限り対応するCSS2プロパティの値と同じである。 値が1つしか指定されなかった場合、その値に必ずマッチしなければならない。 値のリストが与えられた場合、リスト中のいずれかの値にマッチすればよい。 @font-faceの中で値が省略された記述子は、各記述子定義に示す初期値を利用する。
| Value: | [ <family-name> | <generic-family> ] [, [<family-name> | <generic-family> ]]* |
|---|---|
| Initial: | depends on user agent |
| Media: | visual |
定義するフォントのファミリ名を記述するための記述子。 値の取り方は'font-family'プロパティと同じである。 【訳注:後の方で例外を挙げたりするくらいなら「ただし'inherit'は除く」と書いて欲しかった、以下同じ】
| Value: | all | [ normal | italic | oblique ] [, [normal | italic | oblique] ]* |
|---|---|
| Initial: | all |
| Media: | visual |
定義するフォントのスタイルを記述するための記述子。 値の取り方は'font-style'プロパティと同じである。 ただし、値をコンマで区切ってリストにしてもよい。
| Value: | [normal | small-caps] [,[normal | small-caps]]* |
|---|---|
| Initial: | normal |
| Media: | visual |
定義するフォントがスモールキャピタルであるか否かを記述するための記述子。 値の取り方は'font-variant'プロパティと同じである。 ただし、値をコンマで区切ってリストにしてもよい。
注。 「pryamoĭ」系のキリル書体をスモールキャピタルのフォントとして定義しておくと、うまい具合に欧文書体と一貫性が取れて都合がいい。 同様の理由で「kursiv」系のキリル書体を、イタリック体のフォントとして定義しておくとよいだろう。
| 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点は例外:
| 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点は例外:
| Value: | all | <length> [, <length>]* |
|---|---|
| Initial: | all |
| Media: | visual |
定義するフォントのサイズを記述するための記述子。 'font-size'プロパティとは異なり、値には絶対単位の長さしか使えない。 長さの値をコンマで区切ってリストにしてもよい。
初期値になっている'all'という値は、ほとんどのスケーラブルフォントに適していると言える。 したがって、この記述子は主にビットマップフォント、もしくはラスタライズできる範囲が限られたスケーラブルフォントの@font-face定義で利用することになる。
以下の記述子は必須ではないが、目的の文字を描画するにはグリフが不十分なフォントを、無駄に調査したりダウンロードしたりするのを回避するために利用する。
| 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+3000-33FF, U+4E00-9FFF
定義するフォントのem平方の長さを相対的に表す数値を記述するための記述子。 この数値は他の記述子で様々な長さを表現するのに使われる。 したがって、この値に依存する記述子を用いる場合、'units-per-em'の指定は必須である。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
この記述子によって、文字座標系、すなわちグリフがレイアウトされる格子の相対サイズを与えてやる。
この記述子は、フォントをダウンロードするかローカルのものを利用するかに関わらず、実際のフォントデータを参照するのに利用する。 したがって省略は許されない。
| 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(」と「)」の間に入れること。
ローカルフォントへのアクセスは完全名<font-face-name>を通じて行われる。 実際のところ、書体名というのは一意でもなければプラットフォームやフォーマットに対して独立なわけでもないのだが、ローカルにインストール済みのフォントデータを識別するのにはこれが最善の手段であろう。 加えて、グリフについて必要な補完情報を提供してやれば、書体名を利用する手段はより正確さを増すこととなる。 たとえば、そのフォントに含まれるグリフがカバーするISO10646文字コード位置の範囲などを指定するとよい。('unicode-range'を参照)
以下の記述子はCSS2の定義上オプションとなっているが、賢いマッチングやフォントサイズの調整をしたいのならばこれらを利用するとよい。
| 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を参照せよ。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォントの垂直画線幅を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォントの水平画線幅を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | 0 |
| Media: | visual |
フォントの縦ストロークの(垂直軸に対する)角度を記述するための記述子。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
大文字グリフの高さを記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
小文字グリフの高さを記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。 この記述子は'font-size-adjust'プロパティと併用するのが非常に有意義である。 なぜなら、候補に挙がったフォントの縦幅比を計算するには、フォントサイズとx-heightの両方が必要になるからである。 このことから、フォント記述にはこの記述子を含めるよう推奨する。
アクセントを除いた状態におけるアセンダの最高点を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
アクセントを除いた状態におけるディセンダの最低点を記述するための記述子。 値が未定義のままならマッチングに影響しない。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
フォントを加工するとは、最低限指定されたフォントの横幅メトリックをマッチさせる操作である。 その目的を達成するには定義するフォントのメトリック情報を与える必要がある。 また、プログレシブ描画においても、フォントのロード時に内容の再流し込みを避けるにはメトリック情報が必須である。 以下の記述子はCSS2の定義上オプションとなっているが、文書作成者がフォント加工(あるいは上記問題を解決したプログレシブ描画)を利用したいのならばその一部は必須となる。 代替フォントは、目的のフォントが利用可能になればただちに置き換えてしまうべきである。 以下の記述子を指定しておけば、目的のフォントにできるだけ近いものを、できるだけ迅速に提供できるようになる。
以下に示す記述子のうち特に重要なのは、'widths'と'bbox'である。 これらは、目的のフォントが利用可能になった際、テキストの再流し込みを抑制するのに用いる。 更に、マッチングのための記述子も、フォント加工を改善するのに役立つ。
グリフの幅を記述するための記述子。 <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対多・多対多にならざるを得ない用字系でも、なおこの記述子は役に立つ。 つまり、フォント加工のためにではなく、フォントのダウンロードや賢いマッチングのためになら、上記のような用字系でもこの記述子を活用することができる。
フォントの境界ボックスの限界を記述するための記述子。 値には4つの数値をコンマで区切りのリストとして指定する。 これらの数値は順に、境界ボックス左下隅のx座標、同y座標、ボックス右上隅のx座標、同y座標を示している。
| Value: | <uri> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォント記述子は、スタイルシート内のフォント定義に含めてもよいし、別にフォント定義リソースを用意してそれをURIで指し示してやってもよい。 後者のやり方だと、複数のスタイルシートが同じフォントを参照する場合にネットワーク・トラフィックを削減することができる。
以下の記述子はオプションであり、異なる用字系の文字列を揃えるのに利用する。
| Value: | <number> |
|---|---|
| Initial: | 0 |
| Media: | visual |
フォントの下ベースラインの位置を記述するための記述子。 この記述子がデフォルト以外の値(ゼロ以外の値)を取る場合は、'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォントの中央ベースラインを記述するための記述子。 値が未定義のままなら、全グリフの最上部と最深部の間を取るなど適当な決め方をしてしまってもよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォントの数学記号のベースラインを記述するための記述子。 値が未定義である場合、中央ベースラインをそのまま流用するとよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
| Value: | <number> |
|---|---|
| Initial: | undefined |
| Media: | visual |
フォントの上ベースラインを記述するための記述子。 値が未定義のままなら'ascent'の値を流用してもよい。 また、この記述子を利用する場合は'units-per-em'も同時に指定しなければならない。
以下のようなフォントが与えられたとする:
| 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;
}
この章では、クライアント側でフォントのマッチング・加工を行う場合や、Webにアクセスして異なるプラットフォームからフォントをダウンロードする場合などに役立つとされている、フォントの特性を列挙する。 フォントデータを物理的に埋め込む以外の用途で、Web上のフォントを使う必要がある媒体にとっても、これら特性に関する情報は役に立つことだろう。
以下に解説する特性は、フォントを特徴付けるのに用いられており、CSSやスタイルシートの分野に特有な概念ではない。 CSSではたまたまこれらの特性を記述するのにフォント記述子を利用しているが、VRMLのノード、CGMのアプリケーション構造、Java API、CSS以外のスタイルシート言語など、別の表現形式への写像も可能であろう。 フォントの特性を取り扱うのに共通の汎用システムを利用している場合、ある媒体で1度利用したフォントをプロキシにキャッシュして別の媒体で再利用すれば、ダウンロード時間やネットワークのバンド幅を節約することができる。
そのような利用法が可能な媒体を一部列挙しておこう:
ファミリ内の特定の1書体を識別する完全な名前のこと。 普通は、ファミリ名にテキストの特徴に関する様々な修飾語句(特に規則性はない)を付けて完全名とする。 完全名には(多くの場合ファミリ名に続けて)ベンダの名称やその短縮形が含まれることもある。 修飾語句の付け方がプラットフォームによって様々なので、完全名はローカルフォントを参照する場合にのみ用いられる。 また、完全名は必ず引用符で括らねばならない。
完全名の差異については、たとえばTrueTypeのファミリ名とPostScriptのそれとでは、スペースや区切り文字の使い方が異なったりする。 あるいは、システムやプリンタ・インタプリタの都合で名前の長さに制限があると、ある種の単語では短縮形に相違を生じる場合がある。 たとえば、完全名ではごく一般的に使われているスペース文字、これをPostScriptファミリ名に含ませることはできない。 一方、TrueTypeファミリ名には、PostScriptのようにスペース文字が入らない名前も使用可能である。
フォント定義に用いる名前は、あらゆるローカルフォントに対するエイリアスになり得るという意味において非常に重要である。 つまり、プラットフォームやアプリケーションから独立した強力な名前を採用することが肝心であり、特定のアプリケーション、自然言語に依存した名前は避けるべきである。
理想的にはフォントデータの集合を各々一意に識別できるような名前があれば良いのだが、現状ではそうもいかない。 同じ書体名のフォントでも記述子の値はそれぞれである。 カバーするグリフの範囲が違うといった程度なら必要なグリフさえ手に入れば関係ないのでそれほど深刻でもないが、メトリック情報に差異があったりすると、同名のフォントなのに中身は非互換という不都合な事態を招いてしまう。 しかし、この非互換性を常に識別可能にし、なおかつ正しいローカルデータの利用を誤って妨げずにすむような規則はとても定義できそうにない。 したがって、現状で書体名のマッチングを判定するのには、ISO10646文字集合のコード情報だけを頼りにすることとなるだろう。
フォント定義に書体名を記述する主目的は、指定されたフォントデータがローカルに存在する可能性を考慮して、UAが適切な判断を下せるようにしておくことである。 したがって、フォントデータの完全な複製があるならば両者は同じ書体名でなければならない。 さもなくば、マッチングするはずだったローカルフォントを見落として、不必要にWebトラフィックを増大させてしまうだろう。
幅メトリックなどある種の値では、同種同サイズフォントのベースライン間距離を一辺とする、架空の正方形に対する相対値でもって長さを表現する。 この正方形のことをem平方と呼び、グリフのアウトラインを定める際にもこのグリッドが設計枠となる。 この記述子では、em平方が何単位に分割されているかを指定する。 たとえば、Intellifontの値が250、Type 1の値が1000、TrueType、TrueType GX、OpenTypeなどの値が2048、この辺りが一般的だろう。
この値が未指定だと、いかなるフォントメトリック情報も無意味になってしまう。 たとえば、あるフォントでは小文字の高さが450なのに、それより小さいはずの別のフォントでは同890だ、というおかしなことになる。 実際には、前者を450/1000、後者を890/2048というように分数として捉えてやれば、後者の方が小さい値になる。
em平方内における、中央ベースラインの位置を与える。 中央ベースラインは、表意文字の位置揃えに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。
陰にも陽にも、各フォントはそれぞれにフォント符号化表を有しており、そこにはグリフと文字情報の対応関係が収めらている。 また、この表は符号化ベクトルとも呼ばれる。
実際、1つの文字情報に複数のグリフが対応するようなフォントは数多く存在している。 こういったフォントでは、言語特有の規則や文書設計者の意図に応じてグリフを使い分ける。
たとえばアラビア語の場合、すべての文字について4種類(もしくは2種類)の形状が存在する。 そして、その文字が文頭にくるか、文末にくるか、文中にくるか、単独で出現するかによって4者を使い分けるのである。 しかし、いずれのグリフを使う場合にも文字情報は同じであり、ソース文書内での表現は1種類のみである。 印刷した時点で【訳注:もしくは相応の機能を備えたビューアで表示した時点で】、初めて各々が異なる見え方にあんるのである。
また、グリフの形状選択作業を文書設計者に任せるフォントも存在する。 しかし残念ながら、CSS2ではまだこの選択手段を提供することはできない。 現状では、フォント側で勝手に選ぶ形状が常にデフォルトとなる。
書体名からファミリの部分を取り出したものを指定する。 たとえば、Helvetica-Boldのファミリ名はHelveticaだし、ITC Stone Serif Semibold Italicのファミリ名はITC Stone Serifである。 システムによっては、字幅に関する修飾語句をファミリ名の一部にしてしまう場合もある。
フォントの設計枠(em平方)上におけるグリフの幅を、各文字情報ごとに記したリスト。 ISO10646のコード順に記す。 1つの文字情報が複数のグリフに対応する場合や、合字を使わざるを得ない場合、それら特殊なグリフに対して幅を指定することはできない。
フォントの中核となる水平画線についての記述。 フォントを設計する上では複数の画線幅を使い分けるのが普通である。 たとえば、ローマン体の文字で中核となっている垂直画線はセリフ体の「M」や「N」などの文字に見られる細い画線とは大分違うものであるし、同じフォントでも大文字と小文字で画線幅が異なっていたりする。 また、設計上の理由にせよ手違いにせよ、画線幅というものはすべて微妙に異なっていそうなものである。
ラテン、ギリシャ、キリルなどの用字系における、ベースラインから大文字上端までの寸法。 この記述子は、これらの用字系に属するグリフをまったく含まないフォントに対しては、必ずしも役に立つとは限らない。
ラテン、ギリシャ、キリルなどの用字系における、ベースラインから小文字上端(アクセントやアセンダは除く)までの寸法。 これは上端が平らな文字についての話であり、いかなる余計な微調整領域も無視される。 この値は、フォントファミリを比較する手段として、大文字と小文字の高さの比を求めるのに用いられる。
この記述子は、上出の用字系に属するグリフをまったく含まないフォントに対しては役に立たない。 大文字と小文字の高さは、フォントの比較を行うために両者の割合という形で表現されることが多い。 したがって、ヘブライ語などのように活字ケースが1種類のみの用字系においても、大文字と小文字の高さに両方同じ値を設定しておくのはそれなりに意味のあることかもしれない。 すなわち、ラテンとヘブライの用字系が混在するテキストなどで、ヘブライ文字の高さが(ラテンフォントの)大文字と小文字の間の高さになってくれるのである。
em平方内における、下ベースラインの位置を与える。 下ベースラインは、ラテン、ギリシャ、キリルなどの用字系において位置揃えに用いられる。 サンスクリット起源の用字系における上ベースラインと同じ役割を果たす。
em平方内における、数学記号のベースラインの位置を与える。 これは数学記号の位置を揃えるのに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。
仮にフォントに含まれる全グリフを同じ位置に置いて描画した時、その結果できあがった形状を囲い込める最小の矩形のこと。
あるフォントの部分集合を取り出して、別のフォントとしてダウンロード可能にする場合、その境界ボックスは元々のフォントに合わせるべきである。
em平方内における、ベースラインからグリフ最高点(アクセントや発音区別符号は除く)までの寸法。
em平方内における、ベースラインからグリフ最低点(アクセントや発音区別符号は除く)までの寸法。

Panose-1とは、TrueTypeの分類及びマッチング技術の工業標準である。 PANOSEシステムは10種類の数値指定から成り、それらの数値は、ラテン書体の主要な特徴を表すもの、これらの数値を意味付けするための分類手続きを行うもの、与えられた書体の集合からもっとも可能性のあるマッチングを決定するマッピングソフトウェアを表すもの、などに大別される。 このシステムは、修正すればおそらくギリシャやキリル書体にも適用可能だろうが、活字ケースが1種類のみの用字系や表意文字(ヘブライ、アルメニア、アラビア、日中韓などの文字)にはあまり向いていない。
ISO10646(Unicode)における、フォントが含んでいるグリフの範囲。 単独のフォントが含んでいるグリフはごく僅かなので(大半のフォントはISO10646の全範囲をカバーしていない)、この記述子を用いてカバーしているグリフが含まれるブロックや領域を列挙してやる(指定した領域を完全にカバーできるとは保証しない)。 これによって、不適切なフォント(必要なグリフを持っていないフォント)を候補から外すことができる。 この記述子による範囲指定は、フォントから必要なグリフを得られると断定しているわけではなく「試しにダウンロードしてみる価値はある」という程度の意味しか持たない。 詳細情報を得るための有用な文書群については[ISO10646]を参照せよ。
この方法は、構文を変更したり既存文書の内容に何ら不都合をきたすことなく、将来のUnicode文字の割り付け方法に対して拡張可能である。
グリフの範囲についての情報を含み得ないフォントフォーマットでは、陰にあるいは陽にこの特性を利用することとなるだろうが、その値は文書作成者もしくはスタイルシート設計者が与えなければならない。
この他にも用字系の分類方法としてはMonotype system([MONOTYPE]を参照)やISO script systemなどが存在するが、これらは容易に拡張可能ではない。
こういった理由から、本仕様ではフォントごとに正確な分類が可能なISO10646の領域指定によるグリフ分類方法が採用されている。 この方法だと、将来文字の割り付け方がどのように変更されても柔軟に対応可能である。
em平方内における、上ベースラインの位置を与える。 上ベースラインは、サンスクリットを起源とする用字系の位置揃えに用いられる。 ラテン、ギリシャ、キリルなどの用字系における下ベースラインと同じ役割を果たす。
グリフの垂直画線(もしくはほぼ垂直に近い画線)幅についての記述。 ヒンティングと密接な関わりを持つことが多く、いくつかのフォントフォーマットではこの情報を直接抽出することができない。 垂直画線と一言でいっても数種類に(たとえば、通常幅の画線、大文字のMやNなどに用いる軽いウェイトの画線、などのように)分類されるのが普通なので、この値としてはフォントの中核となる垂直画線の寸法を扱うこと。
フォントの中核となる垂直画線の(垂直軸に対する)傾きを反時計回りに度単位で測ったもの。 大半のイタリック体フォントのように右に傾いている場合は負の値をとる。 この記述子は、オブリーク体、スラント体、筆記体など、垂直画線が正確に垂直ではないようなフォント一般に対しても指定してよい。 すなわち、この値が非ゼロだからといって、直ちにそのフォントがイタリック体と断定できるわけではない。
本仕様ではCSS1で示したマッチングアルゴリズムを拡張する。 ただし、文書作成者やユーザのスタイルシートに@font-faceが存在しない場合には、CSS1のアルゴリズムをそのまま利用する。
記述子と書体のマッチングは慎重に行わなければならない。 マッチング処理の結果がUAに関わらず等しくなるように(もちろんこの場合、システムに存在する書体とそれに対応するフォント記述がまったく同じであるという前提付きだが)、記述子を処理する順序を決めておくことにする。 実装が吐き出す結果さえ正しければ、このアルゴリズムはどのように最適化してもよい。
注。 以上に示したアルゴリズムは、各文字ごとにプロパティ調査をするといった面倒な事態を避けるために最適化してよい。
手順2における記述子ごとのマッチング規則は以下の通り:
'font-weight'の値は、'400'(もしくは'normal')をファミリ内の通常ウェイトとしたときの比較値として与えられる。 '400'に対応する典型的なウェイト名にはBook、Regular、Roman、Normal、そして稀にMediumなどがある。
上記以外のウェイトと数値との対応関係は、同一ファミリ内において順序関係を保つことのみを意図している。 UAは視覚的な順序関係が崩れないように名前と数値を対応させなければならない。 すなわち、ある数値に対応する書体が、自身より小さな値に対応する書体に比べて軽いものであってはならない。 UAが書体と数値をどう対応付けるかについては何の保証もない。 ただ、典型的なものとしては以下に示すような方法がある:
'font-weight'の各値について、それより重い書体の存在するなどということは保証しない。 たとえば、通常体とボールド体だけしかないファミリもあれば、ウェイトが8種類にものぼるファミリも存在するのである。
ありがちな対応関係の例を以下に示す。
「Rattlesnake」というファミリに4種類のウェイトがあるとしよう。 軽い方から順にRegular、Medium、Bold、Heavyとすると対応は以下のようになる:
| 書体 | 割り当て | 空きの埋め方 |
|---|---|---|
| "Rattlesnake Regular" | 400 | 100, 200, 300 |
| "Rattlesnake Medium" | 500 | |
| "Rattlesnake Bold" | 700 | 600 |
| "Rattlesnake Heavy" | 800 | 900 |
「Ice Prawn」というファミリに6種類のウェイトがあるとしよう。 軽い方から順にBook、Medium、Bold、Heavy、Black、ExtraBlackとすると対応は以下のようになる。 この例では、UAが「Ice Prawn ExtraBlack」という書体に数値を割り当てていないことに注意すること。
| 書体 | 割り当て | 空きの埋め方 |
|---|---|---|
| "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) |
以下の例では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
}