この規定は,社団法人情報処理学会 情報規格調査会の学会試行標準委員会作業グループ7(WG7)において2009年度までに行われた調査研究をもとに,特に重要と判断される技術情報をまとめ,学会試行標準(IPSJ-TS,以降では試行標準)として公表するものである。
フォントアプリケーションによるフォントの指定を行うとき,最も単純にはフォントリソース名による指定が採用されるが,フォントリソース名では書体の類似性や代替可能性を正しく判断できない。
フォントアプリケーションによるフォントの指定(選択・代替・置換)のために,フォント情報交換規格であるISO/IEC 9541(国内ではJIS X 4161〜4163)は,フォント参照と呼ばれる属性集合を規定している。しかしISO/IEC 9541-2に用意されたフォント参照では,書体の記述は不十分である。例えば,ISO/IEC 9541-2のフォント参照は,指定したいフォント資源のインスタンスの属性を示すだけであって,そのフォント資源を選択した文書作成者の意図を表す属性は用意されていない。文書交換系でフォント参照の利用者が文書作成者の意図を知って適切なフォント資源を選択するには,ISO/IEC 9541のフォント参照の上位概念を扱う属性をも含むことが望まれる。ISO/IEC 9541のフォント参照においては,後の拡張性が考慮されているが,未だにそのフォント参照の拡張は議論されていない。
書体属性記述方式としてMonotypeによるPanose分類があるが,Panoseは欧文書体に特化しており,ラテンアルファベット以外の文字に関する書体記述には不十分である。
そこでISO/IEC 9541のフォント参照の拡張を目標として,既存のフォントの指定・選択・代替に求められるフォント属性を調査し,フォントリソースの参照方式の試行標準として公表することが,フォント業界およびフォント利用者から要求されることとなった。
文書を作成・交換・表示する際に,そこで用いるフォントをリソース名だけでなく,そのフォントを表現する各種フォント属性をも用いて指定することによって,次の事例でのフォントリソースの特定を容易にすることが望まれる。
この試行標準は,これらの利用者要求に応えるフォント指定(選択・代替・置換)を可能にするためのフォント属性をフォントアーキテクチャの一部として規定し,その集合をフォント参照として規定する。フォント参照情報からフォントリソースを選択する際の利用者インタフェースも検討する。
次に示す規格は,この試行標準に引用されることによって,この規定の一部を構成する。
ISO/IEC 9541-1, Information technology - Font information interchange - Part 1: Architecture, 1991-09
備考1 JIS X 4161 が,この国際規格に一致している。
ISO/IEC 9541-2, Information technology - Font information interchange - Part 2: Interchange format, 1991-09
備考2 JIS X 4162 が,この国際規格に一致している。
ISO/IEC 9541-3, Information technology - Font information interchange - Part 3: Glyph shape representation, 1994-05
備考3 JIS X 4163 が,この国際規格に一致している。
日本語フォント実装規約, 1994年度 日本事務機械工業会・実装規約小委員会報告書,1995-03
ISO/IEC 29500-1, Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference, 2011-08
TTC_TECH_01 [TrueType Font] Font Attributes Table for Japanese Kanji (1st edition), TrueType Consortium Japan, 1996-04
フォントに含まれる各グリフについて個別に定義されるく(矩)形で,グリフに外接しているく(矩)形。和文フォントにこの用語が使われることは少ない。
一つのフォント資源に対して一つ定義されるく(矩)形で,すべての外接く(矩)形を含む最小のく(矩)形。
最大外接矩形を隙間無く並べるとグリフが相互に接触する。和文フォントでは,これを避けるために最大外接く(矩)形の周囲に空間を残したく(矩)形を想定してデザインする。このく(矩)形を仮想ボディという。
備考4 仮想ボディを密着させてグリフを並べた組み方をベタ組という。
備考5 仮想ボディは,一つのフォント資源に対して一つ定義される。
備考6 罫線素片などの記号類の一部は,隣接するグリフが接触するようにデザインされる。
備考7 最大外接く(矩)形,外接く(矩)形および仮想ボディの関係を図1に示す。

図1 最大外接く(矩)形,外接く(矩)形および仮想ボディの関係
グリフの包絡形状を近似する図形。
備考8 例えば“上”,“土”は“△”で近似し,“今”,“中”は“◇”で近似する。
備考9 書体デザインの分類に際して,グリフのデザイン傾向を評価するためにこの図形を参照する。欧文書体のデザイン分類ではアセンダ,ディセンダ,xハイトなどの図形的特徴を参照できるが,和文書体ではそれらに相当する概念がない。
備考10 包絡近似図形の例を図2に示す。


図2 包絡近似図形の例
書体属性の値を規定する対象となる文字。
書体見本帳において書体の特徴を示す限られた数の文字。見本帳では数値化できない特徴をも見せる必要があるため,計測文字とは異なる基準で選ばれる。
ISO/IEC 9541は書体デザインを示す属性として,デザイン名,ファミリ名などを用意している。ISO/IEC 9541-1のAnnex Aの書体デザイン分類は,デザインだけを分類基準としているわけではなく,歴史的経緯も分類基準に含まれる。この試行標準では,図形的特徴に基づく書体デザインを示すフォント属性を検討し,フォント代替に際しての参照情報とする。
フォントの混植に際しては,必ずしも図形的特徴に基づく書体選択だけが行われるわけではなく,少ないほうの言語部分を幾分強調して,浮き立たせることを狙うこともある。しかし概ね図形的特徴に基づく書体選択が適用されると考えて差し支えない。
ISO/IEC 9541-1が規定するフォント属性は,当時のDigital EquipmentのJim Flowerのドラフトに基づく。それに日本,US(Xerox, IBM)のコメントを反映したものであり,特に日本のフォントに関しては書体を表わす属性が不十分である。
備考11 Jim FlowerがISO/IEC 9541-1のドラフトを作成する以前のISO/IEC DIS 9541は,7部構成をとり,フォント属性は,DIS 9541-5, Font Attributes and Character Model (Editor: Ronald Pellar) に既定されていた。
5.2においては,計測文字を用いてその値を測定し,数値化できる書体属性を示す。この試行標準で数値化していない属性(重心,腰(漢字揃え線),ふところ(閉領域字幅比)),および数値化が不可能な属性(起筆・収筆,脈絡,エレメント,線質)については解説に示す。
次の書体属性はISO/IEC 9541の中で言及されている(字面率に直接対応するISO/IEC 9541の書体属性はないが,avrlen-height × avrlen-width / (VUNITS x HUNITS)に相当する。)が,和文フォントに関するそれらの属性値については明確な記述がない。そこでこの試行標準では,和文フォントに関する書体属性を明らかにすると共に,附属書Cにおいてそれらの属性の測定方法を示す。
デザインに依存しないウェイトとするために縦画だけを測定の対象とし,計測文字の外接矩形の高さに対する縦画の幅の比をウェイトとする。
高さVUNITSおよび幅HUNITSで規定される面積(仮想ボディの面積)に対する,レンダリングして塗りつぶされた領域の面積(blackened area)の比であり,次式でその値を定義する。
黒み率 = blackened area x 1000 / ( HUNITS x VUNITS )ISO/IEC 9541に従って,計測文字として"米"と"の"を使う。カタカナについては今後の課題とする。
仮想ボディを規定するVUNITS,HUNITSに対する計測文字の最大外接く(矩)形の大きさであって,次式で表わされる。
字面率 = (計測文字の最大外接く(矩)形の面積) x 1000 / (VUNITS x HUNITS)次の3種の字面率を用いることもある。
横字面率 = (計測文字の最大外接く(矩)形の横幅) x 1000 / HUNITSそれぞれ,横組み時の詰まり度合の評価および字送り調整,縦組み時の詰まり度合の評価および字送り調整,並びに黒み率との対比に用いる。
縦字面率 = (計測文字の最大外接く(矩)形の高さ) x 1000 / VUNITS
面字面率 = (計測文字の最大外接く(矩)形の面積) x 1000 / (VUNITS x HUNITS)
(かなを含む)漢字書体と(漢字を含まない)かな書体の二つの側面から書体デザインの図形的な特徴を捉えるための議論を行う。書体の特徴を何によって捉えるかという議論は古くからあり,これらの文献調査と実効性の調査との結果を示す。
特定のベンダの製品サンプルを越える書体分類は多くない。最近の例である小宮山博史による分類と祖父江慎による分類とを比較する。小宮山分類は装飾書体の詳細な分類に力点を置き,祖父江分類は本文書体の詳細な分類に力点を置く。そのため分類の粒度はかなり異なっている。しかし,近年の和文基本書体となっている明朝体,ゴシック,丸ゴシックの分類に関しては,表現は異なるものの,大まかな分類として金属活字からデジタルフォントへの流れの中で
これらの既存の分類ではあまり強調されていないが,デジタルフォント以降の本文書体のデザイン傾向の流れへの反発として, 金属活字の覆刻に基く系統が存在する。これらを金属活字の系統に分類するべきか,さらに新しい流れとして独立に分類するべきかは判断が難しい。
現在の和文文書はその大半を平仮名が占めている。平仮名はその線画の少なさのため,デザインの違いが漢字よりも目につき易いと考えられる。しかし,かな書体を基本として和文書体を分類してよいかどうかを考えるとき,かな・漢字を両方とも含む書体については,かなのデザイン傾向と漢字のデザイン傾向とがどの程度符合しているかが問題となる。かなと漢字のデザイン傾向に関連がなければ,個別に分類しなければならないからである。
そこで,かな・漢字の両方を含むフォントを,かなに注目してかな書体として分類した結果と,漢字書体として分類した結果の両方を示している祖父江分類で調査した。その結果,かな・漢字とも歴史的な変化に注目した分類になっており,区分の取り方が一致している。
フォントデザインの時代的な変化としてふところを広く取る傾向が複数の書体研究者に指摘されている。そこで,字形の詳細な図形的特徴に注目する前に,一般的な特徴としてメトリクの変化について調査し,その結果を図3に示す。縦軸は仮想ボディの高さに対する割合,横軸は仮想ボディの幅に対する割合であり,いずれも1が仮想ボディいっぱいを意味する。同一書体でウェイトが異なるものがある場合には,色を変えて図中に示す。

リョービ築地のかなメトリク

リョービ本明朝のかなメトリク

リョービ平成明朝のかなメトリク

ダイナラブ華康明朝のかなメトリク
図3 メトリクの変化
調査の結果,メトリク最大値に関しては目立った変化がないが,
例外として,平成明朝より後にデザインされたダイナラブの華康明朝は,金属活字のように大きな分散をもつが,その分布は金属活字とは微妙に異る。この差を直接に評価すべきか,または字形の詳細な違いに踏み込んで分類すべきかは,検討を必要とする。
ISO/IEC 9541-1のAnnex Aの書体デザイン分類はデザインだけを分類基準としているわけではなく,分類基準に歴史的経緯を含む。純粋なデザインの上位概念としての"印象"に基づく分類もあり得る。分類ノードの名前は書体名ではない。しかし書体名も書体分類のノード名も固有名詞であり得る。これらの状況把握に基づき,書体分類と分類ノードを検討して,図4に書体分類を示し,図5に対応書体を示す。
a) この書体分類は,ベースとして日本事務機械工業会・実装規約小委員会が開発した日本語フォント実装規約の分類を用い,ISO/IEC 9541の分類との整合性も考慮している。
b) 日本語フォント実装規約の分類に倣って,分類は3階層としている。そのため,とくにディスプレイタイプの分類ではデザインの特徴を分類上で細分化していないが,今後は階層を増やす必要があると思われる。
c) 用途が明確な書体,たとえば新聞用書体,映画字幕書体は,分類上区分している。しかし,OCR書体,ステンシル書体については,単に同種のものであればよいという判定はできず,個々の書体特性に依存するものと考え,分類を分けていない。
フォントベンダによっては学参書体を別分類とし,書体名称に用いているが,"学参用"を特化する弊害を避けて,ここでは無視している。
d) 明朝体,角ゴシック体,丸ゴシック体に関して,クラシックとモダンとの区別を新設している。スタンダードは規定しない。何がスタンダードなのかという基準を決められないからである。オールド,ニューという呼称も採用しない。オールドという表現は多用されていて違和感は少ないが,ニューはこの区分表現に馴染まない。
ここでは,アナログ時代の様式を踏襲しているものをクラシックとし,デジタル時代に入ってから出現した様式をモダンに区分しているが,その中間的特徴を備えたものもあり,明確な基準は設定できていない。
ディスプレイタイプの分類においては,アナログ時代から存在するデザインと,デジタルフォント全盛になってから生まれたデザインとがあるが,これらはクラシックとモダンとに区別しない。それは,ユーザ要求がないことによる。
e) アナログ時代の書体を覆刻した明朝体(漢字)は,クラシックである。原則として背勢処理がなされている明朝体は,クラシックに分類する。
明朝体の定義はさまざまであるが,ここでは三角形のウロコをもつことを必す(須)としている。カタオカデザインワークスの丸明オールドは三角形のウロコをもたず,モトヤのアポロもウロコをもたないという特徴によって,ユービックのユニスクェアは角ウロコをもたないという特徴によって,それぞれ明朝体には分類しない。一方,リョービイマジクスのナウ-Mは明朝体に分類している。
モトヤ明朝はごくわずかな背勢処理がなされているストロークもあるが,実用文字サイズでの視認性を配慮し,モダンに分類している。
f) 明朝体(かな)については,アナログ時代の書体を覆刻したもの,および古い書家の作品をアレンジしたものをクラシックに分類する。デジタル時代になってから誕生した書体であっても,縦組適性重視の思想をもつものはクラシックとする。横組適性重視の書体はすべてモダンとしている。
リョービイマジクスの良寛,小町,行成などは,明朝体およびゴシック体と混植される前提で設計された字形デザインであるが,あくまでも形状特徴から筆字体クラシックに分類している。
g) 角ゴシック体(漢字)についても,背勢処理がなされ,原則として墨溜りをもつゴシック体はクラシックに分類する。ふところの設計など,全体のイメージを活字時代のゴシック体に近似させる手法は,現代には馴染まないため,背勢処理以外の要素によってクラシックとモダンとを峻別することはしていない。
大日本スクリーンのヒラギノ角ゴシックは,背勢処理はなされているが墨溜りをもたないため,モダンに分類する。
h) 丸ゴシック体(漢字)については,アナログ時代のふところの狭い書体はほとんど見向きがされず,ふところの広いデザインが主流になっているため,アナログ時代のもの以外をすべてモダンとした。したがって,分類例では写研の丸ゴシック体だけがクラシックである。
カタオカデザインワークスの丸丸ゴシックは,コーナ円の径が極めて大きく,特異な印象をもつ書体になっているため,丸ゴシック体には分類していない。
i) ゴシック体のバリエーションとも看做せる書体の中に,右ハライが"先細り"にデザインされているものがある。モリサワのフォーク,フォントワークスのぶどうがその例である。同様に明朝体のバリエーションとも看做せるダイナコムウェアの麗雅宋などである。これらはゴシック系,明朝系とはいえないため,ディスプレイ系書体に分類する。
j) ディスプレイ書体において,特にサンセリフPOPは,きわめて多様なデザインの書体が割り当てられる。商用キャッチコピー用書体は,目立つこと,新規性が高いことなどが求められるために,分類は大規模にならざるを得ない。
したがって,本来であれば固有分類対象になるアウトライン,シャドーなども,すべてこの分類の中に入ることになる。これらを組み合せたアウトライン・シャドーなどの書体も出現するからである。若干異なるが,モリサワのカクミンは明朝体と角ゴシック体の中間書体と位置づけられるが,この分類ではセリフPOPに分類している。
k) 独立かなにおいて,分類上はサンセリフを設けたが,現時点では該当書体はない。
| 1.0.0 | 伝統書体(漢字のあるもの) | 4.0.0 Serifs | ||
| 1.1.0 | 明朝体 | 4.12.0 Mincho | ||
| 1.1.1 | クラシック | 4.12.1 Old Style | ||
| 1.1.2 | モダン | 4.12.2 New Style | ||
| 1.1.3 | 新聞明朝 | |||
| 1.2.0 | 角ゴシック体 | 5.0.0 San Serifs | ||
| 1.2.1 | クラシック | |||
| 1.2.2 | モダン | |||
| 1.2.3 | 新聞ゴシック | |||
| 1.3.0 | 丸ゴシック体 | 5.5.0 Geomesric | ||
| 1.3.1 | クラシック | |||
| 1.3.2 | モダン | |||
| 1.4.0 | 筆書体 | 6.3.0 Soft Brush | ||
| 1.4.1 | 楷書体 | 6.3.1 Kaisho | ||
| 1.4.2 | 教科書体 | 6.3.2 Kyokasho | ||
| 1.4.3 | 行書体 | 6.3.3 Gyosho | ||
| 1.4.4 | 草書体 | 6.3.4 Sosho | ||
| 1.4.5 | 隷書体 | 6.3.5 Miscellaneous | ||
| 1.4.6 | 篆書体 | 6.3.5 Miscellaneous | ||
| 1.4.7 | 硬筆・手書き風 | |||
| 1.5.0 | 宋朝体 | 6.5.0 Soucho | ||
| 1.6.0 | 古印体 | |||
| 2.0.0 | ディスプレイ書体(漢字のあるもの) | 7.0.0 Ornamentals | ||
| 2.1.0 | 江戸文字 | |||
| 2.2.0 | 等線 | |||
| 2.2.1 | セリフPOP | |||
| 2.2.2 | ゴシック体系 | |||
| 2.2.3 | サンセリフPOP | |||
| 2.2.4 | 硬筆 | |||
| 2.3.0 | 非等線 | |||
| 2.3.1 | 明朝体系 | |||
| 2.3.2 | 硬筆・手書き風 | |||
| 2.4.0 | 字幕書体 | |||
| 3.0.0 | かな書体(独立) | 6.4.0 Kana | ||
| 3.1.0 | 伝統書体 | |||
| 3.1.1 | 筆字体クラシック | 6.4.1 Old Style | ||
| 3.1.2 | 筆字体モダン | 6.4.2 New Style | ||
| 3.1.3 | 明朝体クラシック | |||
| 3.1.4 | 明朝体モダン | |||
| 3.1.5 | ゴシック体クラシック | 6.4.1 Old Style | ||
| 3.1.6 | ゴシック体モダン | 6.4.2 New Style | ||
| 3.2.0 | 等線 | |||
| 3.2.1 | セリフ | |||
| 3.2.2 | サンセリフ | |||
| 3.2.3 | 硬筆 | |||
| 3.3.0 | 非等線 | |||
図4 書体分類
| 1.0.0 | 伝統書体(漢字のあるもの) | |||
| 1.1.0 | 明朝体 | |||
| 1.1.1 | クラシック | 秀英明朝(大日本印刷) | ||
| 凸版明朝(凸版印刷) | ||||
| 精興社書体(精興社) | ||||
| 石井中明朝(写研) | ||||
| 本蘭明朝(写研) | ||||
| リュウミン(モリサワ) | ||||
| A1明朝(モリサワ) | ||||
| 徐明(モリサワ) | ||||
| TBクラシック明朝(タイプバンク) | ||||
| イワタ明朝体オールド(イワタ) | ||||
| ヒラギノ明朝(大日本スクリーン) | ||||
| 游明朝体(字游工房) | ||||
| 筑紫明朝(フォントワークス) | ||||
| マティス(フォントワークス) | ||||
| S明朝体(ニィス) | ||||
| 1.1.2 | モダン | モトヤ明朝 | ||
| イワタ明朝体(イワタ) | ||||
| 見出しミンMA31(モリサワ) | ||||
| 光朝(モリサワ) | ||||
| ファイン(リョービイマジクス) | ||||
| ナウ-M(リョービイマジクス) | ||||
| TB明朝(タイプバンク) | ||||
| JTCウィンM(ニィス) | ||||
| 小塚明朝(アドビシステムズ) | ||||
| 平成明朝体 | ||||
| 1.1.3 | 新聞明朝 | イワタ新聞明朝体Pro(イワタ) | ||
| 1.2.0 | 角ゴシック | |||
| 1.2.1 | クラシック | 凸版ゴシック(凸版印刷) | ||
| 石井ゴシック(写研) | ||||
| ゴシックBBB(モリサワ) | ||||
| 太ゴB-101(モリサワ) | ||||
| モトヤゴシック(モトヤ) | ||||
| ゴシック体オールド(イワタ) | ||||
| リョービゴシック(リョービイマジクス) | ||||
| 1.2.2 | モダン | ゴナ(写研) | ||
| 新ゴ(モリサワ) | ||||
| ネオツデイ(モリサワ) | ||||
| ゴシックMB101(モリサワ) | ||||
| 新ゴシック体B(イワタ) | ||||
| シーダ(モトヤ) | ||||
| ナウ-G(リョービイマジクス) | ||||
| ヒラギノ角ゴシック(大日本スクリーン) | ||||
| ニューロダン(フォントワークス) | ||||
| ロダンPro(フォントワークス) | ||||
| 筑紫ゴシック(フォントワークス) | ||||
| JTCウィンS(ニィス) | ||||
| 小塚ゴシックPro(アドビシステムズ) | ||||
| 平成角ゴシック体 | ||||
| 1.2.3 | 新聞ゴシック | イワタ新聞ゴシック体Pro(イワタ) | ||
| 毎日新聞ゴシック(モリサワ) | ||||
| 1.3.0 | 丸ゴシック | |||
| 1.3.1 | クラシック | 石井中丸ゴシック体(写研) | ||
| 1.3.2 | モダン | ナール(写研) | ||
| 新丸ゴ(モリサワ) | ||||
| じゅん(モリサワ) | ||||
| モトヤマルベリ(モトヤ) | ||||
| シリウス(リョービイマジクス) | ||||
| ヒラギノ丸ゴシック(大日本スクリーン) | ||||
| JTCウィンR1(ニィス) | ||||
| 細丸ゴシック体(ダイナコムウェア) | ||||
| TB丸ゴシック(タイプバンク) | ||||
| 平成丸ゴシック | ||||
| 1.4.0 | 筆書体 | |||
| 1.4.1 | 楷書体 | 紅蘭細楷書(写研) | ||
| 正楷書CB1(モリサワ) | ||||
| 正楷書(モトヤ) | ||||
| 正楷書体(イワタ) | ||||
| 弘道軒清朝体(イワタ) | ||||
| グレコStd(フォントワークス) | ||||
| DF顔楷書(ダイナコムウェア) | ||||
| DF文徽明体(ダイナコムウェア) | ||||
| DF徽宗宮(ダイナコムウェア) | ||||
| DF痩金体(ダイナコムウェア) | ||||
| DF北魏楷書(ダイナコムウェア) | ||||
| 1.4.2 | 教科書体 | 石井中教科書体(写研) | ||
| イワタ教科書体(イワタ) | ||||
| モトヤ教科書(モトヤ) | ||||
| ユトリロPro(フォントワークス) | ||||
| 1.4.3 | 行書体 | 岩蔭行書(写研) | ||
| ヒラギノ行書(大日本スクリーン) | ||||
| 江川活版三号行書(大日本スクリーン) | ||||
| 祥南行書体(ダイナコムウェア) | ||||
| JTC曲水MYU(ニィス) | ||||
| 1.4.4 | 草書体 | DF草書霜月(ダイナコムウェア) | ||
| JTC淡斎草書「濃」(ニィス) | ||||
| 1.4.5 | 隷書体 | 曾蘭隷書体(写研) | ||
| イワタ隷書体Std(イワタ) | ||||
| 花牡丹-DB(リョービイマジクス) | ||||
| DF郭泰碑(ダイナコムウェア) | ||||
| 1.4.6 | 篆書体 | DF新篆体(ダイナコムウェア) | ||
| JTC淡斎篆書(ニィス) | ||||
| 1.4.7 | 硬筆・手書き風 | 日立つれづれぐさStd R(タイプバンク) | ||
| DF金文体(ダイナコムウェア) | ||||
| クレーPro(フォントワークス) | ||||
| 1.5.0 | 宋朝体 | イワタ宋朝体(イワタ) | ||
| 花胡蝶(リョービイマジクス) | ||||
| DF新宋朝体(ダイナコムウェア) | ||||
| 1.6.0 | 古印体 | 淡古印(写研) | ||
| モトヤ古印体(モトヤ) | ||||
| 康印体(ダイナコムウェア) | ||||
| JTC古印体「歌」(ニィス) | ||||
| 2.0.0 | ディスプレイ書体(漢字のあるもの) | 鈴江戸(写研) | ||
| 2.1.0 | 江戸文字 | 織田勘亭流(写研) | ||
| 勘亭流(モリサワ) | ||||
| 勘亭流(字游工房) | ||||
| DF寄席文字(ダイナコムウェア) | ||||
| いなひげ(写研) | ||||
| 古今髭Std EB(ダイナコムウェア) | ||||
| DF籠文字(ダイナコムウェア) | ||||
| 2.2.0 | 等線 | |||
| 2.2.1 | セリフPOP | カクミン(モリサワ) | ||
| DF優雅宋(ダイナコムウェア) | ||||
| DF麗雅宋(ダイナコムウェア) | ||||
| 2.2.2 | ゴシック体系 | ゴナO(写研) | ||
| ナールSH(写研) | ||||
| スーボ(写研) | ||||
| DFひびゴシック体(ダイナコムウェア) | ||||
| 丸丸ゴシック(カタオカデザインワークス) | ||||
| 2.2.3 | サンセリフPOP | 石井ファンテール(写研) | ||
| ナミン(写研) | ||||
| ミンカール(写研) | ||||
| フォーク(モリサワ) | ||||
| DFブラッシュRD(ダイナコムウェア) | ||||
| DFブラッシュSQ(ダイナコムウェア) | ||||
| DF POP 2 体(ダイナコムウェア) | ||||
| DF綜藝体(ダイナコムウェア) | ||||
| キアロ(フォントワークス) | ||||
| ロゴJr(視覚デザイン研究所) | ||||
| メガ丸(視覚デザイン研究所) | ||||
| 2.2.4 | 硬筆・手書き風 | ナカフリー(写研) | ||
| DFクラフト遊(ダイナコムウェア) | ||||
| DFてがき誠(ダイナコムウェア) | ||||
| DFペン字体(ダイナコムウェア) | ||||
| 2.3.0 | 非等線 | |||
| 2.3.1 | 明朝体系 | アポロ(モトヤ) | ||
| アドミーン(視覚デザイン研究所) | ||||
| 丸明オールド(カタオカデザインワークス) | ||||
| 2.3.2 | 硬筆・手書き風 | ナカフリー(写研) | ||
| はるひ学園(モリサワ) | ||||
| 2.4.0 | 字幕書体 | 映画字幕書体(キネマ・フォント・ラボ) | ||
| 3.0.0 | かな書体(独立) | |||
| 3.1.0 | 伝統書体 | |||
| 3.1.1 | 筆字体クラシック | 良寛(リョービイマジクス) | ||
| 小町(リョービイマジクス) | ||||
| 行成(リョービイマジクス) | ||||
| 弘道軒(リョービイマジクス) | ||||
| 3.1.2 | 筆字体モダン | iroha-31 nire(カタオカデザインワークス) | ||
| 3.1.3 | 明朝体クラシック | 秀英(モリサワ) | ||
| リュウミンオールドがな(モリサワ) | ||||
| アンチックAN(モリサワ) | ||||
| 築地(リョービイマジクス) | ||||
| 築地体仮名(大日本スクリーン) | ||||
| 游明朝体かな(字游工房) | ||||
| 3.1.4 | 明朝体モダン | りょうDisplay(アドビシステムズ) | ||
| コミクス(ニィス) | ||||
| 丸明Yoshino(カタオカデザインワークス) | ||||
| ことのは(朗文堂) | ||||
| 3.1.5 | ゴシック体クラシック | TB築地(タイプバンク) | ||
| 3.1.6 | ゴシック体モダン | ネオツデイ小がな(モリサワ) | ||
| りょうゴシック(アドビシステムズ) | ||||
| 3.2.0 | 等線 | |||
| 3.2.1 | セリフ | |||
| 3.2.2 | サンセリフ | サンクスR(ニィス) | ||
| ロゴアール(アドビシステムズ) | ||||
| 3.2.3 | 手書き風 | ゼンゴN(モリサワ) | ||
| ひまわり(フォントワークス) | ||||
| 丸明Fuji(カタオカデザインワークス) | ||||
| 3.3.0 | 非等線 | DFクラフト童(ダイナコムウェア) | ||
図5 対応書体
金属活字での組版においては活字ごとに文字集合が異なり,一旦印刷したものを拡大・縮小する技術が十分に発達していないため, 大きい文字サイズで組んでおき,これを縮小して印刷するような方式は一般的でなかった。そのため,各文字サイズでの書体設計は それぞれ異なる用途を念頭に置いていた。
このような制限下では,現在の環境では独立に考慮できる
明朝活字字形一覧で調査された各号数の文字数を見ると,五号・四号活字以外では文字数が少なく,本文書体では文字集合,それ以外では文字サイズが重視されていたと考えられる。三号以上の見出し用活字の字形と四号以下の本文用活字の字形とを比べると,必ずしも本文用活字の字形は,見出し用の活字字形を包含していない。例えば,見出し等に用いられる大サイズ活字はウェイトを重くし,本文・註釈用の小サイズ活字にない装飾を加える(本文用三号以上の活字では"支","肢"に筆置きを付加したり,"妃"の旁を"己"ではなく"已"にするなど)ことも多かった。
金属活字の字母作成にベントン彫刻機が導入されると,同一の原図から複数の文字サイズの活字が作成できるようになった。印刷技術の発達によって,より小さい文字サイズでの本文印刷が主流になると,全体的にウェイトが軽くなるなどの変化はあったが,本文用活字に比べ,サイズの大きい活字はウェイトを重くするなどの,サイズごとに異なる用途を念頭に置いたデザインの習慣は維持された。
スケーラブルフォントが用いられる現在では,それぞれのフォントのデザインが想定している文字サイズが明確にされない場合が多い。同一字体を複数のウェイトでデザインしてフォントファミリを構成するという欧文フォントの考え方が和文フォントにも導入され,装飾とウェイトとを独立とする考え方が広まった。
その結果,本来はウェイトの重い見出し用活字に付加された装飾を軽いウェイトの本文用書体にまで導入したもの,本文用活字を拡大して縦画を太くしただけの見出し用書体などが発生した。金属活字では文字集合,文字サイズといった大まかな指定以上の選択肢がなかったが,上述の過程で発生した書体を分類・指定するにはこれだけでは不十分である。
現在の和文書体の指定で重要な要素に,不均一な字送り(プロポーショナル)のフォントがある。
電算写真植字によって字間を任意の距離に設定できるようになると,活版印刷では難しかったツメ組みなどの字送りが不均一な組み方が発生した。字送りが不均一な組み方は,本来は大きな見出しなどに際して本文の組み方と同程度の文字間スペースでは広すぎるように見えることを解消するため,版下作成の際にごく一部を手作業で組んでいたものであったが,欧文のDTPソフトウェアの日本語対応が進み,ページレイアウト自体をワードプロセッサなどで済ませるようなワークフローが広まった結果,本文でも使われるようになった。
製版・インキ・紙質の性能が向上し,本文の不均一な字送りを扱うソフトウェアが整備されたことで,字送りをフォントの側で固定 するよりも,組版の処理系が設定する場合が増えた。その結果,金属活字においては活字の金属棒部分の正方サイズと,文字をデザインする領域の正方サイズとが区別されていたものが,サイズ対比が小さくなったり,極端な場合には全く区別しないデザインが発生している。
プロポーショナル和文フォントは,漢字の字送りは一定なまま,カナ・記号類をプロポーショナルにしたものが多い。このようなプロポーショナルな和文フォントで,欧文の組み方に倣った1ページ2段組両端揃えの文書を組んだ場合,ポイントサイズが同一の 固定幅フォントで組み直すとページ溢れが発生する可能性が非常に高い。
ここでは文書を次のとおりに分類する。
電子化された文書の利用形態として,大まかに次の3分類を考える。
ISO/IEC 29500で標準化されたOOXML,またはその原型となったWord XML (Microsoft Office 2003)では,フォント指定のために,次のパラメタを書き込む。
charsetはsigエレメント内のcsbと重複しているが,csbが様々なCodePageを指定できるのに対し,charsetはCodePage分類での文字集合を一つだけ指定できる。
pitchとfamilyとを別々に書き込む場合もある。
charset, pitchfamilyなどの属性は,Windows GDIに由来する。たとえばpitchfamilyのファミリ分類(ROMAN, SWISS, MODERN, SCRIPT, DECORATIVE)は,TrueTypeフォント形式のファミリ分類とは異なる。しかし,Windows GDIでのフォント指定はこれらの属性で指定するわけではなく,既存のOOXML,Word XML処理系はすべてのフォントを備えた環境下であってもname属性を破損すると,十分に再現しきれない。
この試行標準では,Windows GDIのフォントマッパの挙動を調べて,フォント関連規格および文書規格の中で標準化が可能な部分を検討する。
Windows GDIは,ある描画出力環境(デバイスコンテキスト)を決定した上で,テキスト描画に用いるフォントをハンドルによって指定する。このフォントハンドルは論理フォントと呼ばれ,物理フォント(Windows GDIのChooseFont()によって得られる,処理系で実際に使えるフォント)との関連は隠蔽されている。物理フォントが存在することは,処理系内部にフォントファイルが存在することを意味しない。例えばプリンタドライバが,プリンタに内蔵されたベクタフォントをChooseFont()で返させているだけで,処理系内部にはフォントがないという場合もある。
論理フォントは,OOXMLのフォント関連属性で指定されるフォントに比べると,より具体的である。これは,Windows GDIがラスタフォント,プリンタベースフォントを基本に設計された部分を引き継いでいるためである。(OOXMLでは,ラスタフォント指定に必要な属性は不十分である。) 論理フォント属性にはHeight, Ascent, CharWidthなどがあるが,これはポイントサイズ単位ではなくピクセル単位であり,ラスタフォントとは対応づけられるが,スケールしていない状態でのベクタフォントとは対応づけられない(出力装置の解像度を指定しなければならない。)。
Windows GDIのCreateFont()に幾つかの属性を与えてフォントハンドルを作成するが,この段階では物理フォントとの関連付けは行われず,指定した属性に適合する物理フォントがあるかどうかは確認されない。フォントハンドルと物理フォントとの関連付けは,事後にSelectObject()などを呼び出して行うが,その内部ではWindows GDIフォントマッパによって指定された属性になるべく近い物理フォントをフォントハンドルに対応付ける(常に属性に基づいたフォント代替が行われている。)。Windows GDIフォントマッパは,すべての物理フォントに対して,次に整理する減点法によって指定された論理フォント属性との適合性を評価し,もっとも評点の高いものを関連付ける。
Windows GDIでは,処理系内部のフォントについてもフォントインストーラがメモリ上に展開しておいたフォント資源を使い,物理フォントを指定するためのハンドルは無い。メモリ上に展開されたフォント資源をGetFontData()などによってアクセスできるが,これらのAPIはカレントフォントの資源を取得する設計となっており,デバイスコンテキストまたはカレントフォントを設定せずに物理フォントの情報を取得することはできない。物理フォントを指定するハンドルがないため,物理フォントの属性はメトリク情報の中に含まれるものしか外部に見えない。メトリク情報には,ラスタフォントを意識したTEXTMETRICS構造体と,これをベクタフォントに拡張したOUTLINETEXTMETRICS構造体とがある(OUTLINETEXTMETRICSはTEXTMETRICS構造体をメンバとして含む。)。
TEXTMETRICS構造体について,その属性の根拠となる情報を表1に整理した。Microsoftの技術情報(MSDNなど)では,属性がどのように利用されるかなどは定義しているが,フォントファイルからそれらの属性をどのように決定しているかの情報は含んでいない。この試行標準では属性の定義から,適切と思われるものを選んだ。
ただし,属性によっては単にフォントファイル中の情報を引き写すだけではなく,なんらかの解釈または計算を行う必要がある。具体的には,GDIの書体分類(フォントファミリ分類)はTrueTypeフォントが利用しているIBM書体分類またはPanose書体分類とは異なるため,内部で対応付けを行っていると推測される。TrueTypeフォントからはフォントファイルは重複した情報を含む場合があるので,根拠とできる情報が複数ある場合には列挙している。属性値を決定する際にデバイスコンテキスト情報が必要となるもの(たとえば字高,字幅などはベクタフォントを与えただけでは決定できない。)があるが,それらについては灰色で塗って示している。
表1 WindowsGDIのラスタフォント属性
|
TEXTMETRICS |
Unit |
WinFNT |
TrueType |
|
tmHeight |
72dpiでの1ptのem |
l
dfPoints dfPixHeight |
tmAscent + tmDescent |
|
tmAscent |
dfAscent |
l
OS/2.usWinAscent l
hhea.Ascender l
OS/2.sTypoAscender |
|
|
tmDescent |
tmHeight – tmAscent |
l
OS/2.usWinDescent l
hhea.Descender l
OS/2.sTypoDescender |
|
|
tmInternalLeading |
dfInternalLeading |
OS/2.usWinAscent |
|
|
tmExternalLeading |
dfExternalLeading |
MAX(0, OS/2.sTypoLineGap |
|
|
tmAveCharWidth |
dfAvgWidth |
OS/2.xAvgCharWidth |
|
|
tmMaxCharWidth |
dfMaxWidth |
hhea.advanceMaxWidth |
|
|
tmWeight |
FW_XXX |
dfWeight |
OS/2.usWeightClass |
|
tmOverhang |
72dpiでの1ptのem |
dfCspace |
l
post.isFixedPitch l
OS/2.Panose.bProportional hhea.minLeftSideBearing |
|
tmDigitizedAspectX |
|
dfHorizRes |
未スケール状態では相当するものがない(96?) |
|
tmDigitizedAspectY |
|
dfVertRes |
未スケール状態では相当するものがない(96?) |
|
tmFirstChar |
16bit |
dfFirstChar |
OS/2.usFirstChar |
|
tmLastChar |
dfLastChar |
OS/2.usLastChar |
|
|
tmDefaultChar |
dfDefaultChar |
OS/2.usDefaultChar |
|
|
tmBreakChar |
dfBreakChar |
OS/2.usBreakChar |
|
|
tmItalic |
ON/OFF |
dfItalic |
OS/2.fsSelection.bItalic, OS/2.fsSelection.bOblique |
|
tmUnderlined |
dfUnderline |
OS/2.fsSelection.bUnderline |
|
|
tmStruckOut |
dfStrikeOut |
OS/2.fsSelection.bStrikeOut |
|
|
tmPitchAndFamily |
FF_XXX|XXX_PITCH |
dfPitchAndFamily |
l
post.isFixedPitch l
OS/2.Panose Ø OS/2.Panose.bFamilyType Ø OS/2.Panose.bSerifType Ø OS/2.Panose.bProportional l
OS/2.sFamilyClass l
CFF.TopDICT.isFixedPitch |
|
tmCharSet |
XXX_CHARSET |
dfCharSet |
l
OS/2.ulCodepageRange l
OS/2.ulUnicodeRange l
cmap |
|
tmFacename |
文字列 |
dfFace |
name.FullName |
ベクタフォントの属性であるOUTLINETEXTMETRICSを表2に整理する。ほとんどの情報は,TrueTypeフォントのOS/2テーブルに記述された属性を引き写していると思われる。WinFNTでは,フォントファイル内部には相当する情報がない。注目すべき点は,otmsCapEmHeight, otmsXHeightなど実際には用いられていないと思われる情報も引き写しているが,OS/2.sFamilyClass(IBM書体分類値)はどの属性にも含まれていないと思われる点である。したがって,TrueTypeフォントのPanose書体分類値はフォント検索の際に利用されていると思われるが,IBM書体分類値は参照されていない可能性が高い。
表2 WindowsGDIのベクタフォント属性
|
OUTLINETEXTMETRICS property |
WinFNT |
TrueType |
補足 |
|
otmTextMetrics |
|
|
TEXMETRICS表を参照 |
|
otmPanoseNumber |
|
OS/2.Panose |
|
|
otmfsSelection |
|
OS/2.fsSelection |
|
|
otmfsType |
|
OS/2.fsType |
|
|
otmCharSlopeRise |
|
hhea.caretSlopeRise |
|
|
otmCharSlopeRun |
|
hhea.caretSlopeRun |
|
|
otmItalicAngle |
|
post.italicAngle |
|
|
otmEMSquare |
|
head.unitsPerEm |
|
|
otmAscent |
|
l OS/2.sTypoAscender l hhea.Ascender l OS/2.usWinAscent |
|
|
otmDescent |
|
l OS/2.sTypoDescender l hhea.Descender l OS/2.usWinDescent |
|
|
otmLineGap |
|
l OS/2.sTypoLineGap l hhea.LineGap |
|
|
otmsCapEmHeight |
|
OS/2.sCapHeight |
|
|
otmsXHeight |
|
OS/2.sxHeight |
|
|
otmrcFontBox |
|
head.xMin head.xMax head.yMin head.yMax |
|
|
otmMacAscent |
|
hhea.Ascender |
|
|
otmMacDescent |
|
hhea.Descender |
|
|
otmMacLineGap |
|
hhea.LineGap |
|
|
otmusMinimumPPEM |
|
head.lowestRecPPEM |
|
|
otmptSubscriptSize |
|
OS/2.ySubscript{X,Y}Size |
|
|
otmptSubscriptOffset |
|
OS/2.ySubscript{X,Y}Offset |
|
|
otmptSuperscriptSize |
|
OS/2.ySuperscript{X,Y}Size |
|
|
otmptSuperscriptOffset |
|
OS/2.ySuperscript{X,Y}Size |
|
|
otmsStrikeoutSize |
|
OS/2.yStrikeoutOffset |
|
|
otmsStrikeoutPosition |
|
OS/2.yStrikeoutOffset |
|
|
otmsUnderscoreSize |
|
post.underlineThickness |
|
|
otmsUnderscorePosition |
|
post.underlinePosition |
|
|
otmpFamilyName |
|
name.FamilyName |
|
|
otmpFaceName |
|
name.FullName |
|
|
otmpStyleName |
|
name.StyleName |
|
|
otmpFullName |
|
name.FullName |
|
Windows GDIの論理フォント(LOGFONT)構造体のメンバとこの属性値を決定するためのと資源について,Windows当初の基本フォントであったWindows FNT(WinFNT)および現在の基本フォントであるTrueTypeのフィールドを表3に整理する。
表3 WindowsGDIの論理フォント属性
|
LOGFONT property |
Unit |
WinFNT |
TrueType |
|
lfHeight |
72dpiでの1ptのem |
dfPoints dfPixHeight |
l
OS/2.usWinAscent + l hhea.Ascender+ |
|
lfWidth |
72dpiでの1ptのem |
l
dfAvgWidth dfPixWidth |
OS/2.xAvgCharWidth |
|
lfEscapement |
0.1° |
|
|
|
lfOrientation |
0.1° |
|
|
|
lfWeight |
FW_XXX |
dfWeight |
OS/2.usWeightClass |
|
lfItalic |
ON/OFF |
dfItalic |
l
OS/2.fsSelection.bItalic l
OS/2.fsSelection.bOblique l head.macStyle.bItalic |
|
lfUnderline |
ON/OFF |
dfUnderline |
l
OS/2.fsSelection.bUnderline l head.macStyle.bUnderline |
|
lfStrikeOut |
ON/OFF |
dfStrikeOut |
OS/2.fsSelection.bStrikeOut |
|
lfCharSet |
XXX_CHARSET |
dfCharSet |
l
OS/2.ulCodepageRange l
OS/2.ulUnicodeRange cmap |
|
lfOutputPrecision |
OUT_XXX_PRECIS |
|
|
|
lfClipPrecision |
CLIP_XXX_PRECIS |
|
|
|
lfQuality |
XXX_QUALITY |
|
|
|
lfPitch |
XXX_PITCH |
dfPitchFamily |
l
post.isFixedPitch l
OS/2.panose.bProportional l CFF.TopDICT.isFixedPitch |
|
lfFamily |
FF_XXX |
l
OS/2.panose.bFamilyType l
OS/2.panose.bSerifType OS/2.sFamilyClass |
|
|
lfFacename |
(文字列) |
*dfFace |
name.familyName |
前述の調査結果から,標準化可能な属性を考える。
多くの処理系は文字描画に際して,太字・斜体などの書体合成(これらは本来別個にデザインされたフォントによってファミリを構成するが,存在しない場合に機械的な変形によって太字・斜体を合成する。),回転・白抜き・浮き出し影などのグリフ加工の機能をもつ。
下線・取消し線などの機能も,本来はフォント資源に内在させるのではなく,テキスト描画によって実現されるべき機能であるが,Windows GDI,MacOS QuickDrawなどでもフォント資源にこれらの情報を追加している。
フォントファイルにもこれらの情報を書くことができるが,実際にはフォントファイルの中で実現されることは稀で,文字描画機能の側で実行していることが多い。そのため,これらの属性を標準化しようとすればフォントファイルではなく,文字描画を指示する体系,または文字描画の情報を記録する体系(文書)で標準化しなければならない。
文書がページサイズの概念をもつならば,文字の出力サイズも文書中に記述されるはずである。ベクタフォントのラスタ誤差などを無視できる場合,字高・字幅などの属性も文書によって決定できる。OOXMLではこれらの属性は,スタイル属性であり,フォント属性ではない。
これらには次のような属性がある。
lfOutputPrecision, lfClipPrecision, lfQualityは,特定の出力装置に向けたフォント選択を行う際にフォント種別,精度,処理速度を加味させるための属性である。これらはフォントまたは文書内部にもたせることがむずかしく,フォントを主眼に置く規格による標準化は困難と思われる。
TrueTypeフォントは,ISO/IEC 14496-22 (いわゆるOpenType)として国際標準化され,必す(須)の内部テーブルであるOS/2に書体分類情報を記述する。標準化されているが必す(須)でないテーブルであるPCLTにも記述することができる。Appleによる当初の設計では,クロスプラットフォームはあまり意識されず,TrueType以前のシステムで管理することを念頭に置いていたため,書体分類はTrueTypeフォント外部のテーブルに記述されていた。そのため,OS/2テーブルもPCLTテーブルも含まないTrueTypeフォントが存在することに注意する必要がある。
OS/2テーブルには,IBM書体分類およびHewlett-Packard社によるPanose書体分類での情報が記述される。
IBM書体分類は,二つの4ビットパラメタ(クラス/サブクラス)によって書体を分類する。ISO/IEC 9541を念頭に置いて設計した部分もあるが,基本的には欧文書体の分類観点であり,何らかの数値計測によって分類するものではないため,異なるクラス/サブクラス間の書体の類似性の評価はできない。
これに対し,Panose書体分類は,10個の4ビットパラメタによって書体を分類するが,当初の設計では用字系ごとに独立にパラメタを定義することを意図していた。そのため,10個のうち1個は用字系分類に割当てられ,現在ではラテンアルファベットのセリフ体,サンセリフ体,スクリプト体,飾り記号が定義されている。ただし,ISO/IEC 14496-22におけるPanose書体分類は,正確にはHewlett-Packardによる正式なPanose定義とは異なり,すべての書体でセリフ体のパラメタを用いる。漢字,アラビア文字,ヘブライ文字などの書体設計が大きく異なるものは別扱いとすることが意図されていたが,それらは未定義である。Panose規格票では,アラビア文字のようにPanose値がすべてて未定義となっている場合は,フォント名だけの参照などにフォールバックすることが期待されている。
PCLTテーブルはHewlett-Packardによるページ記述言語PCLにおいて,ページ記述言語内部には含まれていないフォントを処理系が内蔵するフォントで補うための補助情報である。
この情報は,"OS/2"テーブルに含まれるPanose分類情報に類似しているが,完全に同じではない。
TrueTypeで用いられている書体分類は,当初は欧文と和文とを区別して定義できる設計であったが,実装上はすべて欧文のセリフ体およびサンセリフ体の2書体を念頭に置いたパラメタに対応付けるようになっている。
そのため,TrueType Consortium Japanは,TrueType内部の情報をもとに欧文のフォント選択・代替を行う処理系が,同様に和文フォントを扱った際にできる限り混乱が生じないように和文書体を分類し,OS/2テーブルに記述する情報の標準化を行った。
この和文書体の分類項目を次に示す。
さらにTrueType Consortium Japanは,IBM書体分類とPanose値との対応付けをTTC_TECH_01において規定している。
この和文書体分類では,IBM書体分類のクラス/サブクラス,Panose書体分類のファミリ/セリフスタイルの4パラメタを組合せて書体を分類するが,パラメタの意味についてもできるだけ欧文書体の分類と整合するよう定めたため,行書と草書とを区別できていない。IBM書体分類だけ,またはPanose書体分類だけを用いる処理系では,次のとおり分類の粒度が低下する。
備考12 OS/2, PCLTテーブルの利用の現状: OS/2テーブルはPanoseは書かれるようだが,第4〜10パラメタは未定義のものが多い。IBM分類は書かれていないものも多い。PCLTテーブルはほぼすべて書かれているものが多いが,正しいかは不明。
基本的な書体分類体系は5.3に基づき,TrueType Consortium JapanによるOS/2テーブルに書き込む分類情報と整合するように,次の分類を行う。
OS/2テーブルに書き込む書体分類には,IBMによるクラス分類(ISO/IEC 14496-22:2009, Annex B)およびPanose分類があるが,このどちらも装飾書体に関する詳細な分類は行っていない。TrueType Consortium Japanは,IBMによるクラス分類およびPanoseパラメタのうちファミリ分類およびセリフ分類だけを利用する。そのため,ポップ体をすべてPanoseのDecorativeファミリに分類し,さらに詳細な分類はセリフだけで区別可能となっている。
その結果,ポップ体をセリフによって明朝ポップ,角ゴシックポップ,丸ゴシックポップなどと分類している。既存の本文書体を機械変形したポップ体についてはうまく整合するが,独立にデザインしたものをセリフによって分類する手法には限界がある。
広く行われる機械変形のうち,影付け,浮き出し,アウトラインなどの特徴は,OS/2テーブルのfsSelectionおよびheadテーブルのmacStyleに独立パラメタとして書き込めるので,この分類の中では扱っていない。
レイアウト主導の場合,レイアウトに影響を与えるフォント置換は避けるべきで,場合によっては文字集合の維持よりもレイアウトの維持が優先される。したがって,再編集よりもレイアウト維持を重視したデータ形式が望ましいが,現在の事務文書は,レイアウト機能付きワードプロセッサのような"再編集可能な固定長様式文書"によって再編集可能なデータ形式で交換されることが多い。このとき,再編集可能なデータ形式ではレイアウト維持の機能が劣るか,または文書データに十分な情報を埋め込めないため,フォント置換の影響は様々である。
編集可能性が残っていない文書の内部で詳細なレイアウト情報を指定することは難しくないが,編集可能性を残した文書の場合はレイアウト情報ではなくレイアウト規則しか与えられないためである。
大別して次の影響が考えられる。
各々の影響を回避するには,どのような属性に重みをかければ良いかを考慮する必要がある。
Windows GDIフォントマッパが論理フォント情報をもとに物理フォントを選択する場合,すべての物理フォントに対して論理フォント属性をもとにした減点法での採点を行い,最も評点が高いものと関連付ける。評点計算の対象となる属性ミスマッチおよび評価重みを表4に整理する。
表4 WindowsGDIフォントマッパの属性評価
|
Penalty |
Penalty Weight |
Penalty Details |
Source property of
candidate font |
|
CharSet |
65000 |
要求フォントと候補フォントの文字集合に互換性がない |
l
OS/2.ulCodepageRange l
OS/2.ulUnicodeRange l
cmap |
|
OutputPrecision |
19000 |
要求フォントがOUT_STROKE_PRECISフラグを立てているためベクタフォントが必要であるのに候補フォントはベクタフォントでない。 あるいは,要求フォントはOUT_STROKE_PRECISフラグを下げているためデバイス内蔵のビットマップフォントで良いのに候補フォントがベクタフォントである |
|
|
FixedPitch |
15000 |
固定幅フォントを要求しているが候補フォントは可変幅 |
l
post.isFixedPitch l
OS/2.Panose.bProportional l
CFF.isFixedPitch |
|
FaceName |
10000 |
要求フォントと候補フォントのフェース名が異なる |
name.FullName |
|
Family |
9000 |
要求フォントと候補フォントのファミリ名が異なる |
name.FamilyName |
|
FamilyUnknown |
8000 |
要求フォントはファミリ名を指定しているが候補フォントにはファミリ名がない |
nameテーブルにfamily nameが無い |
|
HeightBigger |
600 |
heightが大きすぎる(TrueTypeでない場合) |
|
|
FaceNameSubst |
500 |
要求フォントのフェース名が代替フェース名と一致した(Windows 3.1以降) |
l
フェース名の部分一致 l
処理系が持っているフォント代替表の中にフェース名が一致するものが見つかるかどうか |
|
PitchVariable |
350 |
可変幅フォントを要求しているが候補フォントは固定幅 |
l
post.isFixedPitch l
OS/2.Panose.bProportional l
CFF.isFixedPitch |
|
HeightSmaller |
150 |
heightが小さすぎる(TrueTypeでない場合) |
|
|
HeightBiggerDifference |
150 |
大きすぎるheightの過剰分に比例する減点(TrueTypeでない場合) |
|
|
FamilyUnlikely |
50 |
要求フォントと候補フォントでGDI書体分類が基本書体グループ(Roman/Modern/Swiss)か装飾書体グループ(Script/Decorative)かが食い違う。 |
l
OS/2.panose.bFamilyType OS/2.panose.bSerifType |
|
Width |
50 |
要求されたWidthが非零である場合,要求フォントと候補フォントのWidth差異に比例する減点。 |
OS/2.xAvgCharWidth |
|
SizeSynth |
50 |
ビットマップフォントをGDI拡大縮小する減点。 |
|
|
Aspect |
30 |
出力デバイスのアスペクト比とフォントのアスペクト比の差異による減点。 |
|
|
IntSizeSynth |
20 |
ビットマップフォントをGDI拡大縮小する量に比例する減点。 |
|
|
UnevenSizeSynth |
4 |
ビットマップフォントのGDI拡大縮小が正方でない場合に,縦横比に比例する減点。 |
|
|
Italic |
4 |
要求フォントと候補フォントは斜体設定が食い違い,合成加工機能を使ってもマッチさせることができない。 |
|
|
NotTrueType |
4 |
要求フォントはTrueType形式だが候補フォントは(同名であって)TrueType形式でない場合の減点。 |
フォントフォーマット(glyf, CFFテーブルの有無) |
|
Weight |
3 |
要求フォントと候補フォントのウェイトと異なる場合,ウェイト差に比例する減点。 |
OS/2.usWeightClass |
|
Underline |
3 |
要求フォントは下線なしだが候補フォントは下線がある場合の減点。 |
l
GDIの書体合成機能の設定情報 l
OS/2.fsSelection.bUnderscore l
head.macStyle.bUnderline |
|
StrikeOut |
3 |
要求フォントは取り消し線なしだが候補フォントは取り消し線がある場合の減点。 |
l
GDIの書体合成機能の設定情報 l
OS/2.fsSelection.bStrikeout |
|
VectorHeightSmaller |
2 |
候補フォントがベクタフォントでHeightが小さく,拡大しなければならない場合にHeight差に比例した減点。 |
|
|
DeviceFavor |
2 |
要求フォントは出力デバイス内蔵フォントだが候補フォントは内蔵されていない場合の減点。 |
|
|
ItalicSim |
1 |
要求フォントは斜体であるが候補フォントは合成斜体である場合の減点。 |
l
GDIの書体合成機能の設定情報 |
|
DefaultPitchFixed |
1 |
要求フォントはDEFAULT_PITCHを指定しているが候補フォントは固定幅である場合の減点。 |
l
post.isFixedPitch OS/2.Panose.bProportional CFF.isFixedPitch |
|
SmallPenalty |
1 |
要求フォントが太字または斜体であり,同時にEscapement, Orientationを非ゼロに設定しているが,候補フォントは太字または斜体についてスタイル合成機能を使っていた場合の減点。 |
l
GDIの書体合成機能の設定情報 |
|
VectorHeightBigger |
1 |
ベクタフォントでHeightが大きく,縮小しなければならない場合,Height差に比例した減点。 |
|
減点の重みから判断される属性指定の強さは,
文字集合 > 固定幅指定 > フォント名 > 可変幅指定 > {基本|装飾}書体指定 > ウェイトの配分になる。次の2点に注目する必要がある。
この重み付けを維持したままはん(汎)用のフォント代替を行おうとすれば,フォント名に基づくフォント代替表を細かく整備する必要がある。
ISO/IEC 9541のフォント属性に関する利用者インタフェースの検討例を表5に示す。
表5 ISO/IEC 9541のフォント属性に関する利用者インタフェースの検討例
| ISO/IEC 9541のフォント属性 | 望ましい提示方法 | ||||||||
| fontname | 文字列 | ||||||||
| fontdescription | dataversion | 文字列 | |||||||
| standardversion | 文字列 | ||||||||
| datasource | 文字列 | ||||||||
| datacopyright | 文字列 | ||||||||
| dsnsource | 文字列 | ||||||||
| dsncopyright | 文字列 | ||||||||
| relunits | 文字列(長さが微細なため拡大表示が望ましい) | ||||||||
| typeface | 文字列 | ||||||||
| fontfamily | 文字列 | ||||||||
| postureangle | 角度を図示 | ||||||||
| weight | 数値だが標準的なグリフで示したほうが明確 | ||||||||
| propwidth | 文字列 | ||||||||
| glyphcomp | numglyphs | 文字列 | |||||||
| incglyphcols | 示すのは困難 | ||||||||
| excglyphcols | 示すのは困難 | ||||||||
| incglyphs | 示すのは困難 | ||||||||
| excglyphs | 示すのは困難 | ||||||||
| nomwrmode | 文字列またはアイコン、短いサンプルテキスト | ||||||||
| dsnsize | サンプルテキスト(モニタに収まるのであれば) | ||||||||
| minsize | サンプルテキスト(文字の存在が識別できるのであれば) | ||||||||
| maxsize | サンプルテキスト(モニタに収まるのであれば) | ||||||||
| capheight | サンプルテキストまたはさらに絞り込んだ指標文字 | ||||||||
| lcheight | サンプルテキストまたはさらに絞り込んだ指標文字 | ||||||||
| dsngroup | 文字列 | ||||||||
| minfeatsz | サンプルテキストまたはさらに絞り込んだ指標文字 | ||||||||
| nomcapstemwidth | 原寸図と拡大図を示すことが望ましい | ||||||||
| nomlcstemwidth | 原寸図と拡大図を示すことが望ましい | ||||||||
| wrmodes | wrmode | wrmodename | 文字列またはアイコン、短いサンプルテキスト | ||||||
| wrmode-properties | avgescx | 指標文字(詰め組み)と補助線 | |||||||
| avgescy | 指標文字(詰め組み)と補助線 | ||||||||
| avglcescx | 指標文字(詰め組み)と補助線 | ||||||||
| avglcescy | 指標文字(詰め組み)と補助線 | ||||||||
| avgcapescx | 指標文字(詰め組み)と補助線 | ||||||||
| avgcapescy | 指標文字(詰め組み)と補助線 | ||||||||
| tabescx | 線分により図示 | ||||||||
| tabescy | 線分により図示 | ||||||||
| maxfontext | max-minx | 指標文字(詰め組み)と補助線 | |||||||
| max-miny | 指標文字(詰め組み)と補助線 | ||||||||
| max-maxx | 指標文字(詰め組み)と補助線 | ||||||||
| max-maxy | 指標文字(詰め組み)と補助線 | ||||||||
| sectors | sector | sector-left | カーニング調整したペアとしてないペアの対比 | ||||||
| sector-right | カーニング調整したペアとしてないペアの対比 | ||||||||
| escadjs | adjust | escadjname | 文字列 | ||||||
| adjust-properties | cpea | ncpeaforwd | カーニング調整したペアとしてないペアの対比 | ||||||
| ncpeabackwd | カーニング調整したペアとしてないペアの対比 | ||||||||
| cpeax | カーニング調整したペアとしてないペアの対比 | ||||||||
| cpeay | カーニング調整したペアとしてないペアの対比 | ||||||||
| sec | secx | 文字と補助線 | |||||||
| secy | 文字と補助線 | ||||||||
| minescadjsze | 文字と補助線 | ||||||||
| maxescadjsze | 文字と補助線 | ||||||||
| scores | score | scorename | 文字列 | ||||||
| score-property-list | scoreoffsetx | 文字と下線 (モニタと印刷の差異は?) | |||||||
| scoreoffsety | 文字と下線 (モニタと印刷の差異は?) | ||||||||
| scorethick | 文字と下線 (モニタと印刷の差異は?) | ||||||||
| vscripts | vscript | vsname | 文字列 | ||||||
| vscript-property-list | vsoffsetx | 標準の文字との位置関係がわかるよう図示 | |||||||
| vsoffsety | 標準の文字との位置関係がわかるよう図示 | ||||||||
| vsscalex | 標準の文字との位置関係がわかるよう図示 | ||||||||
| vsscaley | 標準の文字との位置関係がわかるよう図示 | ||||||||
| minlinesp | minlinesp-left | サンプルテキスト2行により図示 | |||||||
| minlinesp-right | サンプルテキスト2行により図示 | ||||||||
| minanascale | サンプルテキストとの対比での図示 | ||||||||
| maxanascale | サンプルテキストとの対比での図示 | ||||||||
| nomalign | 文字列 | ||||||||
| alignmodes | align | alignname | 文字列 | ||||||
| alignment-property-list | alignoffsetx | サンプルテキスト(欧文を含める)によりベースライン比較 | |||||||
| alignoffsety | サンプルテキスト(欧文を含める)によりベースライン比較 | ||||||||
| copyfits | copyfit | copyfitname | 文字列 | ||||||
| copyfit-properties | copy | サンプルテキストと補助線 | |||||||
| dsnwordadd | ワードスペーシングなので長いテキストが必要 | ||||||||
| dsnwordampl | ワードスペーシングなので長いテキストが必要 | ||||||||
| minwordadd | ワードスペーシングなので長いテキストが必要 | ||||||||
| minwordampl | ワードスペーシングなので長いテキストが必要 | ||||||||
| maxwordadd | ワードスペーシングなので長いテキストが必要 | ||||||||
| maxwordampl | ワードスペーシングなので長いテキストが必要 | ||||||||