チュートリアル (その 8)

特定のスクリプトにおいて特に考慮すべき点

Microsoft は、ワードプロセッサが特定のスクリプトに対してデフォルトでどの (OpenType) 機能を用意するべきかに関するいくつかの情報を提供しています。

警告: 機能が文書化されていて、有益そうに見えるからといって、Uniscribe が目的とする用字系でそれを使用するとは限りません。多くのラテン文字フォントは 'init', 'medi', 'calt' などを必要としますが、Uniscribe においては、これらの機能はどれもラテン文字では使用可能になっていません。

Caveat: Just because Uniscribe supports a feature that does not mean any given application will. Uniscribe (as of 2005) supports 'liga' for latin, but neither Word nor Office does. 警告: Uniscribe がその機能をサポートしているからと言って、すべてのアプリケーションがそれを使用可能なわけではありません。 Uniscribe は (2005 年現在) ラテン文字で 'liga' をサポートしていますが、Word も Office もそれを処理しません。

注意: Uniscribe (MS の Unicode テキストレイアウトルーチン) は、用字系によっては GPOS または GSUBテーブルを無視することがあり、GPOS/GSUB に正しいデータが含まれていないとフォント全体の使用を拒絶することすらあります。ヘブライ文字のフォントは GPOS と GSUB の両方を含んでいなければなりません。それらが含まれていないとフォントは使用されません。ラテン文字のフォントはどちらも必要ありませんが、GSUB が含まれていないと GPOS は使用されません。ですから、今のところ、片方のテーブルが存在してもう片方が存在しないときには、FontForge はもう片方のダミー版を出力します。

Microsoft の Sergey Malkin は私に言いました:

Uniscribe 内の各字形エンジンは、レイアウトテーブルのための要求事項に従って決定を行います――それらの一部は GSUB と GPOS の両テーブルを必要とし、ある場合にはどちらのテーブルが存在するだけで十分であり、またはどちらのテーブルも無しで動作するものもあります。

時には、チェックの目的は、フォントが特定の用字系をサポートしているかを決定するだけのこともあります――もし必要なテーブルがそこに存在しなければ、それらのフォントはその字形エンジンによって拒否されるだけです。ときには、我々がまだサポートしなければならない古風な字形生成技術を使用しているフォントが存在するために、フォントを単純に拒否してはならない場合がありますので、旧式のレイアウトコードへフォールバックするためのいくつかのロジックを使用します。

あなたの場合はこれはヘブライ文字で、ここでは OpenType 処理を利用するためには両方のテーブルが存在する必要があります。アラビア文字も両方のテーブルを必要とします。ラテン文字は GPOS を実行するのに GSUB を必要とします。しかし一般には、OpenType の字形生成機能を完全に活用するためには、どの用字系でも両方のテーブルを用意しておくのが安全でしょう。

ラテン文字

Uniscribe は以下の機能をサポートします。

ラテンアルファベットにおいては特に複雑な点はあまりありません。ラテン文字のフォントは一般的に 1 バイトエンコーディングに収まり、フォントテーブルはありません (あってもごく少数です)。 大量のアクセントつきグリフを組み立てる必要があります――またはマークから基底文字への位置指定を使用することができます。 幾つかのグリフの組み合わせについてカーニングを作成するべきでしょう。 いくつかの作成すべき合字 ("f" に関する ff, fi, fl, ffi, ffl や恐らく st も) があります。

1 組の小型大文字を追加したくなるかもしれません。 その場合、Adobe がラテンアルファベットの小型大文字のためのブロックを私用領域に予約しています。

いくつかの言語には、その言語独特の要求事項があります。

ギリシャ文字

Uniscribe は以下の機能をサポートしています。

ギリシャ文字でも、小型大文字を用いる選択が可能です。筆者は、そのためのブロックを私用領域に予約しています――これも廃止されました。

キリル文字

Uniscribe は以下の機能をサポートしています。

キリル文字のフォントも 1 バイトエンコーディングに収まります。少数のアクセントつきグリフがあります。カーニングも作成するべきです。筆者は標準的な合字について詳しくありません。

いくつかの言語は異なるグリフを必要とします ('loca' 機能で指定します)

アラビア文字

Uniscribe は以下の機能をサポートしています。

アラビア文字は語頭、語中、語尾および独立形の完全なセットを必要とします― Unicode はこれらのための領域を予約しています。 また、アラビア文字は膨大な合字セットを必要とします――Unicode は多くの予約領域を設けていますが、ときにはそこに無い合字を必要とすることもあるように思います。 アラビア文字は母音記号を文字の上に配置するために 1 組のマーク (基底文字へのマーク、合字へのマーク) 接続位置を必要とするようです。 アラビア文字においては、グリフ分解テーブルも必要となるでしょう。

筆者は、アラビア語の良質なタイポグラフィを実現するためには、1 グリフごとに 4 個より多くの字形が必要であることを教えられました。 どのようにこれをサポートするべきかについてはよく知りません。

右から左へ書きます。

ヘブライ文字

Uniscribe は以下の機能をサポートしています。

ヘブライ文字は複数の語尾形をもちますが、これらのための特別なテーブルは必要ありません。ヘブライ文字はカーニングを必要とするようです。ヘブライ文字は、母音記号を文字の上に配置するために 1 組のマーク (基底文字へのマーク) のテーブルを持っているべきです。ヘブライ文字はグリフ分解テーブルを必要とするでしょう。必要な合字については筆者は詳しくありません。

右から左へ書きます。

インド系の諸用字系

Uniscribe は以下の機能をサポートしています。

インド系の各種スクリプトは一組の合字セットを必要とします。

(これらはより多くの情報を必要とするでしょうが、私はそれに関して詳しくありません)

ハングル

Uniscribe は以下の機能をサポートしています。

ハングルは音素を表すアルファベットから組み立てられた音節文字のセットから構成されています。 一般的にフォントは組み立て済みの音節文字からなります。

複雑さは、これら全ての音節の膨大な組合せ的爆発が原因です。 これは、PostScript では CID-keyed フォントによって緩和されます。

縦書きと、左から右への横書きが併用されます。いくつかのグリフ (例えば括弧) は縦書き時には異なる方向をもちます。

日本語と中国語 (および韓国語の漢字)

Microsoft は、(私の知る限り) これらの用字系について記述していません。

これも膨大なグリフ集合が必要であり、PostScript では CID keyed フォントを使ってこれを扱っています。

縦書きと左から右への横書きが併用されます。いくつかの文字 (例えば括弧) は縦書き時には異なる方向を持ちます。

-- -- 目次 -- --