フォントをWindowsで動作させる

原文: Make your font work in Windows
タグ: トラブルシューティング
執筆者: Rainer Erich Scheichelbauer
2024年10月2日更新
（初版公開：2024年4月23日）

あなたも、Windowsでフォントを正しく動作させようとして苦労したことがありますか？「Windows被害者の会」へようこそ。

フォントを制作する際、私たちが通常気にかけるのは「Webブラウザ」「Adobeアプリ」そして「Windows」という3つの環境です。中でも特に厄介なのが、Windows版のWordです。ここできちんと動作すれば、他のどこでも問題なく動作すると言えるでしょう。

Wordといえば、フォントの扱いに関してはMac版とWindows版でかなりの違いがあります。この記事ではWindows版に焦点を当てますが、Mac版Wordとの違いについても適宜注記を加えています。

TrueType
テストインストール
グリフセット
ファミリー
バーティカルメトリクス
ヒンティング
OpenTypeフィーチャー
カラー
カーニング
1. カーニングの最後の手段
リンクと詳細情報
関連記事
1. 関連

TrueType

Windows向けのフォントを制作する場合、TTF（拡張子 .ttf）として書き出し、CFF（拡張子 .otf）を避けるのが賢明です。これには明白な理由が2つあります。

第一に、一部の機能、特にドキュメントへのフォント埋め込みはTrueTypeフォントを必要とします。CFF形式は埋め込むことができません。さらに、PostScriptベースのOTFを使ってWordからPDFを書き出すと、そのアウトラインはラスタライズ（ビットマップ化）されてしまいます。以下は、Windows版Wordから書き出されたPDF上の「O」の左上部分の拡大図です。

信じられないかもしれませんが、これは事実です。これが作り話だったらどんなにいいかと思いますが。

第二に、TTFはCFFよりもパフォーマンスが優れています。複雑なアウトラインを持つフォントの場合、CFFでは単語を入力した後、文字が画面に一文字ずつ表示されるのを腕を組んで待たなければならないほど遅くなることがあります。公平を期すために言えば、これはかなり複雑なフォントでの事例ですが、TTF版では同じフォントでも問題なく動作しました。ですから、結論としてWindowsにはTTF一択です。

また、TTFにはデジタル署名、いわゆる「DSIGテーブル」が必要です。これがないと、Windows版WordはそれをOpenTypeフォントとして認識せず、合字やカーニングといったOpenTypeフィーチャーが機能しません。デフォルトでは、GlyphsはTrueTypeの書き出し時に空のDSIGを自動的に追加します。しかし、カスタムパラメータ「Export DSIG Table（DSIGテーブルを書き出し）」を使えば、強制的に追加したり、逆に抑制したりできます。最近のWindows版WordではDSIGが不要になったという噂もありますが、後方互換性のためだけでなく、多くのフォント販売プラットフォームなどのテスト環境が「DSIGがない」と警告を出してくるため、いずれにせよ含めておいて損はありません。

テストインストール

テスト環境として最善の策は、App Storeにある「Parallels」のような仮想化ソリューションです。Windowsがあらかじめ付属しているサブスクリプションを入手してしまいましょう。そしてついでに、Microsoftから「Office 365」のサブスクリプションも契約してください。これ1つで最大5ユーザーまでOfficeをインストールでき、副次的なメリットとしてMac版Officeも同じライセンスで利用できます。

フォントのインストール機能は、MicrosoftがAppleよりも優れている数少ない点の一つです。必要なのは、フォントファイルを右クリックし、非常に分かりやすい「その他のオプションを表示」を選ぶことだけです。

その後、2番目のコンテキストメニューが表示され、そこから「インストール」を選択できます。

「これのどこがAppleより優れているんだ？」と思われるかもしれません。確かに、フォントファイルに対して最も行いたい操作の一つである「インストール」をするために、2回もコンテキストメニューを経由しなければならないのは退屈な仕様です。しかし、素晴らしいのはここからです。フォントを再インストールする必要がある場合、もう一度同じ手順を行うだけで済みます。古いフォントのインストールは上書きされ、即座に新しいバージョンが有効になります。フォントキャッシュの問題に悩まされることはありません。この点に関して言えば、マイクロソフトは良い仕事をしました。

インストールが完了したら、Ctrl+D または Ctrl+Shift+F でアクセスできる「フォント」ウィンドウから、Word上でそのフォントを選択するだけです。

実際には、テキストを選択するとすぐに、フォントピッカーのミニバージョンがポップアップ表示されます。

システムからフォントを削除するのも簡単です。「PC > ローカルディスク (C:) > Windows > Fonts」に移動してください。ここにはインストールされているすべてのフォントがファミリーごとにグループ化されて表示されます。右クリックしてコンテキストメニューから「削除」を選択すれば完了です。

もしファミリー全体ではなく個別のフォント（ウェイトなど）を削除したい場合は、まずファミリーのアイコンをダブルクリックしてフォルダを開いてください。

グリフセット

「Win 1252」文字セットは必ずカバーするようにしてください。それに加えて、想定されるエンドユーザーがキーボードで入力する可能性のあるすべての文字も含める必要があります。

そうしないと、「フォールバックフォントによる置換」のリスクが生じます。つまり、ユーザーが何かを入力した際、あなたのフォントに含まれていない文字をうっかり打ってしまったとします。すると、Windows版Wordを含む多くのOfficeソフトは、その文字をサポートしている「最初に見つかった別のフォント」に切り替えて表示します。恐ろしいのはここからです。その文字だけでなく、その後に入力されるすべての文字もその別のフォントに変わってしまうのです。文字通り、あなたのフォントが勝手に変更されてしまうわけです。

「Win 1252」文字セットについては、Glyphsのサイドバーにある「言語 > ラテン語 > レガシーエンコーディング」を参照してください。ついでに、Mac版Wordでの同様の問題を避けるため、そこにある「Mac Roman」もカバーしておくと良いでしょう。

特に、すべての引用符とダッシュを網羅しているか確認してください。これらはフォントビューのサイドバーの「カテゴリ > 句読点 > 引用符」および「ダッシュ」にあります。これは非常に重要です。なぜなら、Wordはユーザーの入力中に引用符やダッシュを自動的に「スマート（曲線）」なものに置換する機能があり、それがフォントのフォールバック（意図しないフォントの切り替わり）を引き起こす原因になり得るからです。

もし制作中のフォントに等幅（Monospaced）のライニング数字が含まれているなら、それをデフォルトの数字に設定してください。そうしないと、Windowsユーザーからクレームが来ることになります（ここで警告しましたよ！）。これを行うには、「フォント情報 > 書き出し」にある「Rename Glyphs（グリフ名を変更）」と「Update Features（フィーチャーを更新）」というカスタムパラメータを使って、書き出し時に処理させることができます。

「Rename Glyphs」パラメータには、以下のようなコードを記述します。これは、標準的なグリフ命名規則に従っており、接尾辞なしのプロポーショナル数字がデフォルトで、.tf 接尾辞付きの等幅数字が存在すると仮定した場合の例です。

zero=zero.lf
one=one.lf
two=two.lf
three=three.lf
four=four.lf
five=five.lf
six=six.lf
seven=seven.lf
eight=eight.lf
nine=nine.lf
zero.tf=zero
one.tf=one
two.tf=two
three.tf=three
four.tf=four
five.tf=five
six.tf=six
seven.tf=seven
eight.tf=eight
nine.tf=nine

上記のコードは、まず既存のプロポーショナル数字を .lf 接尾辞付きのセットに移動（リネーム）させます。次に、.tf（等幅）数字をデフォルトの名前（接尾辞なし）に移動させます。「Update Features」パラメータは、lnum（ライニング数字）と tnum（等幅数字）フィーチャーを自動的に再計算してくれるので、これで準備完了です。

ファミリー

複数のフォントでファミリーを構成する方法について言及すべきことは、すべて「命名規則」のチュートリアル」に網羅されています。

要点を言うと、Wordは「RIBBI」ファミリーしか認識しません。RIBBIとは、Regular、Italic、Bold、Bold Italicの略です。フォントメニューでファミリー名を選び、「B」ボタンや「I」ボタンを押すことで、他のメンバー（ボールドやイタリック）に切り替えるという仕組みです。

これはつまり、「B」や「I」ボタンで到達できないスタイルは、別のファミリーとして扱われることを意味します。結果として、RIBBI以外のウェイト（例えばBlackなど）は、アルファベット順にソートされた「別のエントリ」としてフォントリストに並びます。つまり、「Black」は「Semibold」よりも前に表示されることになります。それぞれのイタリック体には、そこから「I」ボタンで切り替えることができます。

もしこの仕様が気に入らないとしても、残念ながらどうしようもありません。これがWindows（少なくともWindows版Word）のフォントメニューのロジックなので、受け入れるしかありません。WordをInDesignに変える魔法のようなハックは存在しないのです。Microsoftでさえ、自社製品のフォントメニュー内でフォントを綺麗に並べ替えることはできていないのですから。

ちなみに、Mac版のMicrosoft Officeでは挙動が異なります。Mac版では、すべてのスタイルがファミリーごとにまとめられ、ファミリー内では幅（Width）とウェイト（Weight）のクラス順に正しくソートされます。

ウェイトクラスについてですが、「使用すべき最小のウェイトクラスは250である」という話を聞いたことがあるかもしれません。かつてWordは、それ以下のウェイトクラスに設定されたフォントを「表示するには細すぎる」と判断し、人工的に太らせて表示してしまう仕様があったからです。しかし良いニュースがあります。もはやその制限を気にする必要はありません。このウェイトクラスのバグは20年以上前に修正されました。ですから、1から1000までのウェイトクラス全範囲を自由に使用できます。後方互換性が心配ですか？お願いですから、気にしないでください。四半世紀も前のWordを使っているような物好きなユーザーが、あなたのフォントにお金を払うとは思えません。つまり、その市場セグメントは無視しても安全です。

命名に関して2つアドバイスがあります。第一に、名前は短く保ちましょう。ファミリー名もスタイル名もです。Windowsのフォントメニューの表示幅は非常に狭く、名前が長すぎると古いバージョンのWindowsではフォントが「無効」であると警告されることがあったからです。ただし、Windows 11以降では長い名前も問題なく扱えるようです。

第二に、一部の文字の組み合わせは名前で使用できないようです。少なくとも「NOR」（すべて大文字）という文字列については、問題が確認されています。名前にこれを含めると、フォントがWordのフォントメニューに表示されなくなります。おそらく、ブール演算子の「NOR（否定論理和）」のように、コーディング用に予約されている単語に関連していると推測されますが、不思議なことに「AND」は名前に使っても問題ありません。もし何を試してもフォントが表示されない場合は、名前を変更してみて、それが解決策になるか確認してください。もし他にも禁止されている文字の組み合わせを発見した場合は、フォーラムでお知らせください。この記事を更新します。

バーティカルメトリクス

バーティカルメトリクスの基本的な考え方は、以下の3つのメトリクス設定の間で、良い同期（あるいは妥協点）を見つけることです。

OS/2 winAscent および winDescent
OS/2 typoAscender、typoDescender、typoLineGap
hhea ascender、descender、lineGap

そして、常に「OS/2 selection bit 7」を有効にしてください。これは「Use Typo Metrics（タイポメトリクスを使用）」とも呼ばれますが、Glyphs 3以降ではデフォルトで有効になっています。

本来、これらのメトリクスは次のように機能すべきです。「OS/2 Win値」は描画のクリッピング（見切れ）判定のみに使用されるべきです。そして行の位置決めには、Windowsは「OS/2 Typo値」を、Macは「hheaメトリクス」を使用すべきです。

しかし悪いニュースがあります。「Use Typo Metrics」がオンの場合、Windows版Wordは「OS/2 Typo値」をクリッピング判定と行の位置決めの両方に使用してしまいます。これはバグですが、近いうちに修正される可能性は低いです。

ちなみに、Mac版Wordはどのビットが設定されていようと、行の位置決めとクリッピングの両方に常に「hhea値」を使用します。したがって、どのような戦略をとるにせよ、常にTypo値とhhea値を互いに同期（同じ値に）させ、重要なグリフのいずれもクリッピングされないように十分な高さを確保してください。

これは、ラテン文字とアラビア文字など、垂直方向の寸法が大きく異なる文字体系を組み合わせる必要がある多言語フォントにとっては頭の痛い問題です。そのような場合、あなた（またはクライアント）は、「タイトな行間」を取るか、「画面上でグリフが見切れないこと」を取るか、決断しなければなりません。申し訳ありませんが、Wordではその両立は不可能です。

ヒンティング

もし ttfautohint を使用する予定なら、「Windows Compatibility（Windows互換性）」オプションをオンにしてください。これにより、OS/2のwinAscentとwinDescentの位置にアラインメントゾーンが追加され、意図しないクリッピングが発生する可能性が減ります。ttfautohintでのヒンティングに関するその他の詳細については、ヒンティングのチュートリアルを参照してください。

OpenTypeフィーチャー

正直に言うと、フィーチャーを正しく機能させることは、このプロセスの中で最も不可解な部分です。ここで推奨されるすべてを行っても、Windows版Wordでフィーチャーが機能しないことがあります。なぜでしょうか？理由はわかりません。

しかし確実に言えることは、フォントにDSIGテーブルが含まれていること（前述の通り）、そして「フォント情報 > フィーチャー」で「Language Systems（言語システム）」が適切に設定されていることを再確認する必要があるということです。さもないとWordは機能してくれません。良いニュースとして、Glyphsはこれを自動的に行いますが、時々「Update（更新）」ボタンを押す必要があるかもしれません。

Windows版Wordでフィーチャーが機能しているか確認するには、Ctrl+D を押してフォントメニューを開き（まだ選択していなければフォントを選び）、次に「詳細設定」タブに進みます。そこで、OpenType機能のオプションがすべてグレーアウト（無効）されていて絶望するか、

あるいは、シャンパンのボトルを開けて祝うことができます。なぜなら、それらが実際に利用可能になっているからです。

このウィンドウの存在は、クライアントに教育する必要があるものでもあります。あなたは今、Wordのフォントウィンドウにある「詳細設定」タブの存在を知っている世界人口の0.1%に入りましたが、クライアントは全く知らない可能性が高いでしょう。他のアプリではデフォルトでオンになっているべきOpenTypeフィーチャーも、Wordではユーザーが手動で有効にする必要があり、それはまさにここで行わなければなりません。

はい、その通りです。一度に1つのスタイルセットしか有効にできず、しかもその名前はメニューに表示されません（「セット1」のような表記です）。ですから、スタイルセットを増やしすぎないようにするか、いくつかのセットを別のセットに統合するオプションを提供することを検討してください。もっとも、ほとんどのWindowsユーザーはスタイルセットの存在すら知らないので、あまり心配しすぎる必要はないかもしれません。

PowerPointに関しては、いかなるOpenTypeフィーチャーも機能しません。PowerPointのコードベースは非常に古く、柔軟性がなく、壊れているため、PowerPointで何か高度なことをしようと考えるのは時間の無駄です。

カラー

Windows版Wordは、他のアプリと同様に「CPAL/COLR」形式をサポートしています。したがって、もしカラーフォントが必要なら、カラーフォントのチュートリアルに従うだけで大丈夫です。

しかし…恐縮ですが、注意点が一つあります。カラーフォントの技術を混ぜることはできません。純粋なCPAL/COLRである必要があります。特に、SVGテーブルは絶対に追加しないでください。もし追加すると、Wordはすべての色情報を無視し、モノクロのフォールバックレイヤーのみを表示します。

ため息が出ますね。クロスプラットフォーム互換のカラーフォントに関しては、現状こんなものです。私たちの推奨：TTFの書き出し設定では、カスタムパラメータを使用して「Export COLR Table（COLRテーブルを書き出し）」を有効にし、「Export SVG Table（SVGテーブルを書き出し）」を無効にしてください。「ファイル > フォント情報 > 書き出し」で設定できます。

カーニング

Microsoft製アプリでカーニングを反映させることは、それ自体が一つの「科学」のような難しさですが、過去に成功したいくつかの方法があります。しかし、すべてを正しく行っても機能しない状況があるかもしれません。では、始めましょう。

カーニングが機能するための条件：

単一のルックアップにまとめる: ペア調整カーニングは、「フォント情報 > 書き出し」に追加された Keep Kerning in one Lookup（カーニングを1つのルックアップに保持）というカスタムパラメータを使って、単一のルックアップにマージする必要があります。
GPOSフィーチャーの存在: フォントには少なくとも他に1つのGPOSフィーチャーが必要です。「マーク対ベース (mark)」または「マーク対マーク (mkmk)」の位置決めフィーチャーがあれば十分です。Remove Features（フィーチャーを削除）パラメータでフォントを軽量化しようとする際は、これら2つを削除しないよう注意してください。
ユーザーによる有効化: 「フォント」ウィンドウ（Ctrl+D、上記参照）の「詳細設定」タブで、カーニングを有効にする必要があります。その際、「カーニングを行う最小サイズ」を「1ポイント」のような極端に低い値に設定します。なぜMicrosoftがユーザーにこのような面倒な操作を強いるのか、私に聞かないでください。

場合によっては、カーニングは「エンコードされた（Unicodeを持つ）グリフ間」でのみ機能するとユーザーから報告されています。私はそれを確認できていませんが、もしそうなら、エンコードされていないグリフにPUA（私用領域）コードを追加してみて、改善するか試すことはできます。私の推測では、それでもうまくいかないでしょう。ただし、「カーニングを平坦化」しない限りは。それは何かですって？読み進めてください。

カーニングの最後の手段

OK、何をしてもカーニングが機能しない場合はどうすればいいでしょうか？最後の手段として試せる3つのハックがあります。

バリアブルフォントに切り替える

PowerPointでカーニングを機能させることを含め、Windowsでの多くの問題に対する解決策として、意外にも「バリアブルフォントとして書き出す」という方法があります。「ファイル > フォント情報 > 書き出し」で、新しいバリアブルフォント設定を作成し、「フォント」タブでデフォルトのファミリー名とは異なるファミリー名を設定します。これはフォント名の競合を避けるために必要で、通常はファミリー名に「Var」や「Variable」を追加します。次に、「ファイル > 書き出し > Variable」経由で書き出します。

運が良ければ、これで解決です。私のテストでは、悪名高い非互換性を持つPowerPointでさえ、これでカーニングが機能しました。

distハック

実際には、Wordでさえ無視できないOpenTypeフィーチャーがいくつかあります。なぜなら、それらは一部の言語スクリプトがOfficeで正しく表示されるために不可欠だからです。その一つが「Distances」フィーチャー、略して dist です。これは南アジアおよびブラーフミー系文字の表示に必須であるため、常にオンになっています。

この dist フィーチャーに便乗して、その中でカーニングのルックアップを呼び出すことができます。すでに Keep Kerning in one Lookup カスタムパラメータを追加していると仮定して、必要な作業は以下の通りです。 Add Feature（フィーチャーを追加）という別のカスタムパラメータを追加し、dist フィーチャーを選択して、以下の行を記述します。

lookup kern_DFLT;

これは kern フィーチャー内の最初のルックアップの名前になります。dist は kern フィーチャーの後に追加されるため、そこからそのルックアップを呼び出すことができるのです。すべて正しく行っていれば、以下のようになります。

もし Keep Kerning in one Lookup パラメータでそれらを一つのルックアップにまとめていない場合は、次のようになります。

lookup kern_DFLT;
lookup kern_latn;
lookup kern_cyrl;
...

このように、カーニングを持つすべてのスクリプトに対して、kern_XXXX のルックアップ呼び出しを追加します（XXXXはOpenTypeスクリプトタグ）。カーニングを持たないスクリプトや、フォントに含まれていないスクリプトは避けてください。

しかし、これはあくまでハックであることを覚えておいてください。 他のアプリでフォントが誤動作する原因になる可能性がある、いわば「捨て身の策」です。現在のバージョンのWordでは機能し、クライアントは喜ぶかもしれませんが、他のアプリでは機能しないかもしれません。さらに悪いことに、OpenTypeフィーチャーを完全に壊す可能性すらあります。ですから、私はこれをお勧めしません。私の経験では、最近のOfficeのバージョンでは機能しないことさえあります。でもまあ、あなたの場合は違うかもしれませんし、ラッキーかもしれません。

カーニングを平坦化する

通常、OpenTypeフォントでは、カーニング情報は kern フィーチャーに保存され、これはGPOS（グリフ位置決め）テーブルの一部です。この方式の素晴らしい点は、「グループカーニング（クラスカーニング）」ができることです。本質的に、グループカーニングとは、「A」と「Y」をカーニングすると、「ÄY」「ÃY」「ÁY」、さらには「AÝ」や「ÅŸ」のようなあり得ない組み合わせでさえも、同じようにカーニングされることを意味します。なぜなら、これらの文字はすべて「Aグループ」と「Yグループ」の一部だからです。

OpenType以前の「暗黒時代」には、kern フィーチャーを持つGPOSテーブルのようなものはありませんでした。したがって、グループカーニングも存在しませんでした。kern テーブルを使って、個々のグリフ同士をペアでカーニングすることしかできませんでした（はい、フィーチャーではなくテーブルです）。kern テーブルと kern フィーチャーを混同しないよう、この古いテーブルは「旧式kernテーブル」や「プリOpenType kernテーブル」と呼ばれることがあります。いずれにせよ、昔のフォントは200グリフ程度しかなく、カーニングペアも1000〜2000程度で済んでいたため、kern テーブルの制限は大きな問題ではありませんでした。しかし今日では、基本的なフォントでさえ500グリフ以上あり、何万もの潜在的なペアリングが生まれ、古き良き kern テーブルの容量限界をすぐに超えてしまいます。

では、あえてGPOSテーブルを粉々に砕いて、代わりにこの「旧式のカーニングテーブル」を持たせたらどうなるでしょうか？結局のところ、私たちの祖父たちが石と木の棒で最初のコンピュータを作ったような大昔には、それは常に機能していたのですから（PowerPointでさえも！）。

はい、それは実際に機能しますが、それはフォントを壊すことを意味します。もはやグループカーニングはなくなり、最も重要なグリフ間のペアだけに絞るためのサブセット化（間引き）を行う必要があり、その過程で多くのカーニング情報を失うことになります。

これが、mekkablue scriptsの「Kerning > Kern Flattener」スクリプトが行うことです。まず、フォントを複製し（つまりコピー上で作業し）、定義済みの数のグリフペアに対して個別のカーニングを追加し、すべてのグループカーニングと、もしあればGPOSフィーチャーを削除します。その結果、「ウィンドウ > カーニング」はグループなしで以下のようになります。

最後に、書き出すインスタンスに、よく隠されたトップシークレットのカスタムパラメータを追加します。それは Export kern Table（kernテーブルを書き出し）です。

これにより、GPOSテーブルの kern フィーチャーが抑制され、代わりに旧式の kern テーブルがTTF書き出しに追加されます。（このパラメータはCFF OpenTypeフォントでは機能しません。なぜなら、OpenType以前のPostScriptフォントには kern テーブルが存在せず、構造が全く異なっていたからです。）

ファイルの複製から書き出しを行い、その後、保存せずに閉じてください。なぜなら、そのファイルはあなたのフォントの「壊れたバージョン」に過ぎないからです。次に、その新しい書き出しファイルをWindowsにインストールし、Officeで試してみてください。

幸運を祈ります。