また、ウエイトバリエーション（太さのバリエーション）と仮名バリエーションの豊富さもヒラギノファミリーの大きな特徴で、当社では現在、全54書体のヒラギノOpenTypeファミリーをラインナップしています。

欧文フォントでは従来からペアカーニング情報の実装は一般的でしたが、日本語フォントに実装されるようになったのはOpenTypeが初めてです。OpenTypeではさらに、欧文グリフだけでなく和文グリフにもペアカーニング情報が実装できます。ヒラギノOpenTypeでは、Proフォント、Stdフォント、仮名Stdフォントのすべてのフォントに欧文グリフおよび和文グリフのペアカーニング情報が実装されていますので、最小限の手間で高品質なプロポーショナル組版を実現できます。

こちらにヒラギノOpenTypeの日本語ペアカーニングに関する情報をご用意いたしましたのでご覧ください。

IVS（Ideographic Variation Sequence）は、標準のUnicodeで規定されている様々な字体を使用可能にする技術です。 IVSは、漢字を表すUnicodeの直後に異体字セレクタ(Variation Selector)と呼ばれるコードを入力することで、プレーンなテキストデータとして異体字を表現することができます。例えば「葛」であれば、U+845Bの直後にU+E0100の異体字セレクタを付加することで、異体字を表現することができます。

CIDフォントに対するStdフォントの利点は、StdフォントはOpenTypeのため、ダイナミックダウンロードによりプリンタフォントが不要です。クロスプラットフォーム対応やUnicode対応など、OpenTypeならではの特徴も活かせます。また、OpenTypeレイアウトフィーチャと呼ばれる組版テーブルを搭載しますので、それに対応したInDesign 2.0Jなどの組版ソフトでは、キメ細かい組版上の調整が容易に行えます。さらに、ヒラギノOpenTypeのStdフォントは、Proフォントと同様に欧文グリフ・和文グリフの両方にペアカーニングテーブルを搭載していますので、より高品質な欧文組版や和文の詰め組を行っていただけます。

このように弊社Stdフォントは、収容グリフ数を除いては、Proフォントにひけを取らない十分なスペックを装備しています。

MacからWindows（またはその逆）など、プラットホームを変更される場合はフォントをコピーするのではなく、製品に付属のMac用またはWindows用のインストーラーを使用し「機種変更」の手順にそって再インストールしてください。

さらにヒラギノOpenTypeでは、高品質な欧文組版や和文詰め組には必須のペアカーニングテーブルを、ProフォントだけでなくStdフォントにも実装いたしましたので、StdフォントでもProフォントと同等の品質の組版を行っていただけます。

a) グリフ置換情報は、漢字の異体字切り替えや、非漢字の字形切り替え、全角と半角など文字幅の異なる同種のグリフの切り替え、などを実現するための情報です。すべてのグリフがUnicodeで指定できるわけではないため、特に大きなグリフセットをサポートするフォントではこれらの情報はとても重要です。InDesign2.0日本語版では、字形パレットの字体切り替え機能や、文字パレットの「OpenType機能」で、この情報を利用しています。

b) グリフ位置調整情報は、全角幅の仮名グリフに個々に文字幅を与えてプロポーショナル幅とし、プロポーショナル組版を実現したり、特定のグリフとグリフの間を詰めるペアカーニングを実現するための情報です。InDesign2.0日本語版では、文字パレットの「カーニング」の指定を「メトリクス」とすることで、ペアカーニングを含む高精度な和文プロポーショナル組版が実行できます（欧文グリフのペアカーニングは「カーニング」を数値指定しない限り常に有効です）。

c) 仮想ボディ情報は、その名の通り、和文書体の仮想ボディ位置に関する情報です。何を今さら、と思われるかもしれませんが、実は従来形式のフォント（OCF、CID、TrueType）には、仮想ボディ位置を明示的に指定するための情報はなかったのです。そのため、従来形式のフォントではアプリケーションやフォントによって、文字の位置や並びが一定しないなどの問題がありました。OpenTypeではこの点が改善され、アプリケーションが各フォントの仮想ボディ位置を参照することで、精度の高い安定した組版が行えます。

ヒラギノOpenTypeのProフォントとStdフォントは、収容グリフ数が倍以上も異なりますので、両者の差分のグリフ部分については互換性はありません。では、両者に共通するグリフ（Adobe-Japan1-3のグリフ）については互換かと言うと、これも完全に互換とは言えません。

これは、ProとStdで特定のUnicode符号位置に割り当てるグリフの文字幅バリエーションが異なる場合があるためで、Unicodeに依存して文字処理を行うアプリケーションでは、ProフォントからStdフォント（またはその逆）に書体変更すると、同じコードの文字でも文字幅が変わってしまうことがあります（例：Stdでは数学記号のΣや√にAdobe-Japan1-3内の全角グリフが割り当てられているが、ProではAdobe-Japan1-5内のプロポーショナルグリフが割り当てられている場合）。したがって、書体変更はProフォント同士またはStdフォント同士で行う方が安全と言えます。

この件に関し、アプリケーション開発者の方から「StdフォントとProフォントの共通グリフ部分はUnicodeマッピングも共通にすべきではないか。でないと組版の互換性が維持できない」とのご意見をいただいたことがあります。しかし、StdとProのUnicodeマッピングを合わせると、今度はProフォント単体でのUnicodeマッピングの一貫性が損なわれます。たとえば、数学記号のある文字はプロポーショナルグリフで、別のある文字は全角グリフで表示されるとしたら、これも不都合です。ヒラギノOpenTypeでは、各フォント単体での利便性・一貫性を優先しました。

Unicodeは原則として文字幅を規定しません。シフトJISコードでは各コードポイントに暗黙の文字幅属性がありましたが、Unicodeはそうではありません。文字幅属性も含めた情報交換や組版処理が必要なアプリケーションでは、その内部処理として、Unicodeだけでなく文字幅属性の差異（グリフの差異）を識別できるような実装が必要です。その識別に必要な情報はOpenType内部に実装されていますから（「5.5 OpenTypeレイアウトフィーチャーって何ですか？」を参照）、あとはアプリケーションの実装次第と考えます。