フレームつき

よくある質問 (と、これまで訊かれた質問の多く)

FontForge に関する一般的な質問

フォントに関する一般的な質問

FontForge の使い方・各種システムへのフォントのインストール方法

フォントの変換

ヒントと TrueType 命令に関する質問

フォントフォーマットに関する質問

数学的な質問

雑多な質問


なぜフォントエディタを? もう十分にフォントはあるのでは?
それは……違います。もしそうなら私はこのソフトを書いたりしませんでした。
  1. ラテン文字のフォントはたくさんあります。それに比べて、ギリシャ文字・キリル文字・インド系文字・タイ語・中国語・日本語・韓国語・Unicode のフォントはずっと少ない…。
  2. 古い書字システムの研究者は、自分自身のフォントをデザインしなければならない場合がよくあります。
  3. ラテン文字ですら、伝統的には芸術や建築に新しいスタイルが生まれるごとにそれに伴う書体のスタイルが新しく作られました。現代では、時代の美意識を反映するために常に新しいフォントが作られています。
  4. コンピュータフォント技術は常に変化しています。10 年前に有用であったフォントフォーマットは現在役に立ちません。
  5. あなたが既存のフォントに満足だったとしても、それが完全でない可能性はあります。
    • 不足の合字
    • 不足のアクセントつき文字
    • それに合うキリル文字又はギリシャ文字のグリフ
  6. 誰もが、自分自身の手書き文字をフォントにしたいと思います。
  7. フォントで遊ぶのはとても楽しい。

FontForge は単にフォントを作成・編集するだけではない用途にも使えます。あるフォーマットから他のフォーマットに変換することができます。フォントファイルから情報を取り出すこともできます。または、フォントをインストールしないで、それがどのように見えるかを表示するだけのために使うこともできます。

私はなぜそれを書いたのか?
なぜ私はそれを人にあげてしまうことにしたか?
なぜ FontForge は非標準のウィジェットセットをベースにしているのか?
私は、Unicode を適度にうまく扱えるウィジェットセットが欲しかったのです。とくに、私は双方向テキストがヘブライ語とアラビア語のタイポグラフィにとって重要であると考えたからです。それを行えるウィジェットセットを知らなかったので、自分で書きました。
それと、私はチェックボックスがチェックされているかチェックされていないかが本当に見分けられるウィジェットセットが欲しかったのです。私の目にはどっちがどっちだか区別のつかない場合が多すぎたもので…。
なぜ FontForge は C++ で書かれていないのか (または なぜ C++ が私のお気に入りの言語でないのか)?
私がこの質問を受けたときはちょっと驚きました。自分の言語の選択を弁明しなければならないとは知らなかったもので。でもそうらしい……。

基本的に、私はオブジェクト指向を実践することがほとんどの場合に役立たずであると考えているからで、それに加えて、私は C++ があまりに複雑で悪いデザインであると考えているうえに、私はそれを簡単にデバッグできないからです。

上に書いたのは私の個人的な経験に基づいた個人的な意見で、なぜ私が C++ を使わないかの説明です。あなたの意見はこれとは違うでしょう、C++ コンパイラを書くのに 5 年間を費した人はほとんどいませんから。

フォントを改変することは合法か? 倫理上の問題はないのか?
法律上の事柄は国ごとに様々です (恐らく国内でも違いがあります)。決定的な答えが知りたければ、弁護士に相談するべきです。ここに示すのはいくつかのガイドラインです:

あなたがフォントとともに入手した使用許諾を見て、この件に関してそれには何と書かれているかを見てください。

TrueType (および OpenType 並びに潜在的には CID キー指定フォント) には、OS/2 テーブル内に FSType と呼ばれるフィールドがあり、そこには他の人がこのフォントに対して何をすることができるかについてフォントデザイナーが制限を課すことができます。もしこのフィールドが変更を禁止している場合、FontForge は、あなたがフォントデザイナーからこのフィールドの制限を無視することの合意を得ているかどうかを尋ねます。

米国の法律についての私の理解するところは以下のとおりです (ただし、これに頼る前に弁護士のチェックを得てください):

私の理解では、ほとんどのヨーロッパの国々では、フォントのデザイン (形) を複製することを禁ずる法律が存在します。

追加、または訂正があれば歓迎します。その他の国でフォントに関する規定のある法律についてに情報も歓迎します。

12 ポイントのフォントとは何か? (ポイントサイズは、フォントのどこを計って決めるのか?)
あるフォントが 12 ポイントの高さをもつのは、(ベタ組みの) テキストで隣接する 2 行のベースライン同士の間隔が 12 ポイントである時です。

ポイントサイズは、フォントのどのグリフのサイズにも基づいていません。

フォントが金属で作られていた時代に戻ると、フォントのポイントサイズは、そのフォントとともに用いられていた込物の高さと同じでした。

ある意味ではこれはフォントのサイズの計り方としてあまりいい方法ではありません (いくつかのフォントはアクセントまたはアセンダやディセンダに他のフォントより多くの空間を取っているため、実際のグリフの高さはより小さくなることになります)。

グリフの x ハイトに基づいた計測体系もあります。

英米ではポイントとは伝統的にパイカポイント (1 インチの 72.27 分の 1) のことでしたが、ヨーロッパではポイントはディドーポイント (1 インチの 67.54 分の 1) のことでした。ヨーロッパではわずかに大きなポイントを使用していますが、英国とヨーロッパのフォントは同じサイズであることが分かっています。ほとんどのヨーロッパの諸言語ではアクセントを使うのに対して、英語では (ごく稀な場合を除いて) アクセントを使用しないので、ポイントのサイズがわずかに増えたことによってアクセントのための空間がより多く取ることができます。

(もちろん、現在ではほとんどのヨーロッパ人はデスクトップソフトウェア上でパイカポイントを使うことを強いられており、ほとんどのコンピュータフォントは現在アクセントつきグリフを含んでいます。ですからこれらの区別とその必然性は消え去ったと言えるでしょう)。

フォントの行間を設定するにはどうすればよいか?
その方法は、出力しようとしているフォントの種類、使用しているオペレーティングシステムの種類、そして運によって異なります。
自分が作ったフォントをどうやってインストールすればいいのか?
えーこれはあなたがどのシステムで作業中か、あなたが作ったのはどのタイプのフォントかに大きく依存します:
Unix 上の X (KDE を除く)
Linux フォント HOWTO ファイルを調べることを提案します。また、font deuglification HOWTO はよい出発点となるでしょう。しかし私も要点をざっと述べておきましょう。

本質を言えば、1 個 (または数個) のディレクトリを「フォントディレクトリ」に割り当てます。フォントをそのディレクトリに移動します。X が必要とするいくつかのデータ構造を構築し、あなたのフォントパスにこのディレクトリを組み込むように X に指示します。残念ながら異なるバージョンの X および X フォントサーバは微妙に異なる習慣を使用します。以下に挙げる手続きはあなたの所では多少変更する必要があるでしょう。

例えば、あなたが frabnuts-13.bdf という名前の BDF フォントをインストールしたい場合、以下のようにする必要があるでしょう:

$ mkdir my_fonts
$ mv frabnuts-13.bdf my_fonts
$ cd my_fonts
$ bdftopcf frabnuts-13.bdf >frabnuts-13.pcf
$ mkfontdir
$ xset fp+ `pwd`

こうすればあなたのフォントはインストールされたことになります。この後、あなたが X を起動するたびにあなたのフォントがどこにあるかを思い出さなければなりませんので、     $ xset fp+ /home/me/my_fonts
という記述を .xsession (または等価なファイル) に記述する必要があるでしょう。

PostScript フォントをインストールしたい場合
フォントは PostScript バイナリ (.pfb) ファイルとして出力するべきです。それから .pfb と .afm の両方のファイルをフォントディレクトリ (のどれか 1 つ) に移動し、そこで type1inst を実行してください。
type1inst はおそらく、あなたのフォントに製造所 (foundry) が含まれておらず、おそらくエンコーディングが間違っているだろうと文句を言うでしょう。以下のいずれかの方法が可能です:

  • 無視する。悪い事は何も起こらないでしょう。
  • type1inst を実行した後で、これらの項目を修正するために fonts.scale を手で編集する。
  • フォントの Copyright を適切な値に設定し、それから type1inst を編集してあなたの製造所名を追加する (このやり方は、type1inst その物に書いてあります)。

TrueType フォントをインストールしたい場合
フォントディレクトリに .ttf ファイルを移動してから mkttfdir と mkfontdir を実行します。
(mkttfdir には、FontForge で作られたフォントの扱いに関する小さな問題があります。それは必ずと言っていいほど確実に製造元が認識できないと警告してきます。無視しても何ら問題はありませんが、それを煩わしく感じるならば ttmkfdir.c の 936 行目に以下の 1 行を追加してください。
            { "PFED", "FontForge" },

いくつかのバージョンの X (例えば、redhat に同梱のもの) は、フォントの処理を X サーバそれ自身で行うのではなく、X フォントサーバに頼っています。chkfontpath を使用してフォントサーバのフォントパスに新しいディレクトリを追加する必要があるでしょう (xset fp ではなく)。 また、フォントディレクトリ (およびその上位ディレクトリ) は万人に対して読み出し可能でなければなりません (フォントサーバは非特権ユーザとして実行されます)

私は、X が OpenType をサポートしているという発言をまだ見たことがありませんが、FreeType はサポートしている (また、X のラスタライザは FreeType を使用しているはずである) ので、X はそれらもサポートすることができるでしょう。ただし、それをインストールするには fonts.scale を手で編集する必要があります (mkttf は、OTF ファイルをサポートしていない freetype1 を使用しています)。

この説明では訳が分からないでしょう。私は優秀な書き手ではないことと、X を設定する方法には多くの選択肢がありすぎることを言い訳しておきます……。

KDE
(私は KDE について深く知りませんので、私の経験については眉に唾をつけて読んでください) KDEでは、kfontinst と呼ばれるツールがあり、これが必要なすべての設定を行うものと考えられています。私はこれを動かすために root になる必要があり、私のシステムを以下の習慣に従うように再設定する必要がありましたが、いったん設定が終われば X へのフォントのインストールはごく簡単に行うことができました。私は、自分が ghostview フォントをどうやってインストールするかについてはまったく分かりませんでした (私が試したのは version 0.9.2 です)。
TeX
TeX は独自の (プラットホーム独立な) フォントインストール用のシステムを備えています。私は自分の経験した限りの事柄をこの文書の別の場所で説明しました。
Windows
TrueType フォントの Windows へのインストールは、そのマシンの \Windows\Fonts ディレクトリにフォントをドロップすることによって行います。フォントをインストールする前に、実行許可ビットを有効にする必要があるでしょう。
フォントを直接 \Windows\Fonts に出力しないでください。それではうまく動かないようです (少なくとも私の XP マシンでは)。フォントをいったん別のディレクトリに出力してから、\Windows\Fonts にドラッグ & ドロップしてください。
Type 1 フォントを使用したい場合は、Adobe Type Manager をインストールして、以下の手順に従う必要があるでしょう。 OpenType フォントを古いシステム (たしか、Windows 2000 よりも前だと思います) にインストールしたいときは、ATM をインストールする必要があります。最近のシステムでは OpenType は TrueType と同じように扱うことができます。
Macintosh OS 9
ったく…。Mac はフォントをリソースソースに張りつけ、独自のヘッダをつけて固めたデータ構造に納めています。Mac のフォントは他のどのシステムとも互換性がありません。FontForge は、フォントを MacBinary エンコーディングに固めたときはリソースフォークを作成することができます。より詳しい情報は以下の質問を参照してください。私は、あるフォーマットから別のフォーマットに変換するちょっとしたユーティリティも書いていて、それらは役に立つことが実証済みです。
一度フォントを変換してしまえば、それをシステムフォルダにドロップするだけで、その後すぐ使えるようになるでしょう。
Macintosh OS X
OS X では、フォントはトップレベルの Library/Fonts ディレクトリ (デフォルトでは /Mac OS X/Library/Fonts/) に置くか、System/Library/Fonts ディレクトリか、またはそのユーザに一致する Fonts サブディレクトリ (~/Library/Fonts) に置くことができます。 リソースフォント (MacBinary ラッパから展開したもの) または dfont のどちらも使用できます。通常の TTF および OTF ファイル (つまり、Unix や MS Windows で使えるのと同じファイル) も使用できます。 私の言える限りでは、昔の NFNT ビットマップリソースは私の OS 10.2 では動きません。ビットマップを使いたい場合は、TTF ファイルまたは sfnt に固めてください。ただし、Type1 リソースフォントを使いたい場合は、(役に立たない) ビットマップフォントも一緒に生成し、それらを両方インストールする必要があります。
どうして FontForge で作ったフォントが MS Windows のシステムにインストールできないことがあるのか?
フォントを直接 \windows\fonts ディレクトリに出力しないでください。フォントを別のディレクトリに出力して、その後に Windows のドラッグ & ドロップ操作で fonts ディレクトリに移動してください。

古いバージョンの FontForge が出力したフォントは Windos 2000 (および XP) システムにインストールできないと聞きました。

私は、これらの問題は (2003年10月20日現在) すでに解決済みであると信じています。それより古いバージョンをお使いの方はアップグレードをお願いします。
フォントを別のマシンからコピーしてきた場合、フォントファイルの実行ビットが設定されていることを確認してください (これを Windows の UI 上で行う方法を知りませんが、cygwin では $ chmod +x foo.ttf とすれば変更できます。)

マク用のフォントを編集するにはどうすればいいの?
Mac OS/9 (またはそれ以前)
伝統的に Macintosh はフォントをファイルのリソースフォークに格納してきました (OS/8.5 頃から後では、Mac は裸の .ttf ファイルのサポートも行っていると思います)。これは Mac 以外のすべてのマシンでは、リソースフォークの概念がまったく無いために、問題となります。
Macintosh の 1 個のファイル全体を他のシステムで扱える 1 個のパッケージに格納する目的のプログラムがいくつかあります (最もよく使われているのは MacBinary と BinHex です)。FontForge はこれら両方のフォーマットをどうやって読むかを知っており、それらのどちらからでも PostScript フォントや TrueType フォントを読み出すことができます。FontForge はフォントを MacBinary フォーマットで作成することもできます (両方の出力フォーマットのサポートが必要となる理由は見当たりませんし、MacBinary のほうが少し単純だったので)。
そういう訳で、Mac のフォントを編集する手順は以下のようになります:
  1. System Folder:Fonts フォルダにあるファイルを見つける
  2. ファイルを Unix マシンにコピーする
    • Fetch を使用し、MacBinary フォーマットを指定する。
    • または BinHex のような、ファイルを直接作成できるツールを使う
  3. それを FontForge で開く
  4. 編集する
  5. フォントを再び MacBinary フォーマットで保存する
  6. それを Mac に返送する
    • Fetch は自動的に MacBinary ラッパを展開し、正しいファイルにします
    • またはその他各種のツールでも展開できます。
  7. それを元のシステムフォルダにドロップする (それにより、自動的に Fonts に転送されます)

注意: 元のフォントファイルを別の場所に移すか、(PostScript フォント用の) フォント名を FontForge で書き換えたうえで新しいユニーク ID をつけておくことを忘れないでください (フォント情報ダイアログを参照してください)。

警告: PostScript フォントは、最低 1 個のビットマップフォントが付属していないと Mac では役に立ちません。PostScript フォントを出力するときには、NFNT (これは FOND を含んでいます) も一緒に出力する必要があります。
警告: Mac は、PostScript ファイルを格納しているファイルの名前にはうるさいのです。この名前は PostScript フォント名に基づいていますが、変換をかけたものです。このファイルの名前を変更しようと試みないでください。基本的なルールは以下の通りです (Adobe Technical Note 0091 を参照してください):

  • フォント名は、大文字で始まるいくつかの単位文字列に分解される。
  • 最初の単位文字列には、大文字で書かれた先頭文字の次に 4 個の小文字を続けることができる。
  • 残りの単位文字列には、大文字の後ろには小文字 2 文字しか続けることができない。
  • 英字以外の文字 (少なくともハイフン) は取り除かれる。
    これにより、TimesBold ⇒ TimesBol, Helvetica-BoldItalic ⇒ HelveBolIta, NCenturySchoolbook ⇒ NCenSch と変換される。
Mac OS X
Mac OS X では (XDarwin がインストールしてあれば) FontForge を直接起動することができます。OS X にはいくつかのフォントフォーマットがあり、いくつかのフォントは古いフォーマット (上記参照) で格納されており、一方そのたのものはデータフォークリソースとして格納されています。データフォークフォントファイルの拡張子は、ふつう ".dfont" です。Mac では、FontForge はどちらのフォーマットも直接編集できます。OS X は通常の .otf および .ttf 形式のフォントファイルもサポートしています。

Mac OS X は NFNT ビットマップフォーマットをサポートしていないようです。それでも未だに、リソースベースの PostScript を使用する際には NFNT フォーマットのビットマップフォントが含まれている必要があります (おそらく、実際に必要なのは NFNT リソースではなくてそれに付随する FOND リソースだと思いますが、裸の FOND リソースを出力する何らかのデータを書き出すようにする予定はありません)。

どうすれば Mac のフォントファミリーを作れるのか? (フォントをグループ化して、イタリックやボールドのスタイル指定が動作するようにするにはどうしたらいいか?
ほとんどすべての Mac アプリケーションの「書式」メニューであなたのフォントが動作するようにするには、フォントファミリーを作成しなければなりません。これを行うには、ファイル(F)→Macファミリーを出力(F) コマンドを使用します。

同じファミリーに含まれるフォントには、すべて同じファミリー名をつけなければなりません (フォント情報ダイアログを参照してください)。フォントファミリーは Carbon (OS 9 で使われていた古いフォント処理メカニズム) と、(OS X の) ATSUI とでは扱いがかなり異なります。

Carbon では、フォントファミリーが使えるのは、1980 年台前半のコンピュータフォント技術を反映している、Mac の "FOND" リソースに限られています。現代的なコンピュータフォントは、これでは表しきれない変種を含むことがしばしばあります。FONDS は以下のスタイルの任意の組合せをサポートします (ただし Extend と Condense は同時に指定できません):

Mac の FOND は "Black", "DemiBold", "Light", "Thin" または "Extra-Condensed" のような変種をサポートしていません。

一方、ATSUI の下では、ファミリーは同じ FamilyName をもつ一定のリソースファイルに含まれるすべてのフォントから構成されているようです。

どちらのシステムでもファミリーが役に立つようにするに、Apple は 1 個のフォントファイルに 2, 3 の FOND を格納しているようです。各 FOND には関連するフォントのサブファミリーが含まれています。それらの 'FOND' は以下のように分散しているようです:

以下のスタイルをもつフォントのファミリーがあるものとする:
Regular, Bold, Italic, Bold-Italic, Condense, Condense-Italic, Oblique, Light, Light-Italic, Black
その場合、FOND がサポートするスタイルを含んだフォントファミリーを作成するべきである。この場合は以下のようになるだろう:
Regular, Bold, Italic, Bold-Italic, Condense, Condense-Italic
これらのそれぞれに、エレメント(L)→フォント情報(F)→[Mac] を用いて、フォントのファミリー名に使われる FOND 名を設定すること。

他のスタイルの FOND 名を別の名前に設定して、Oblique スタイルには FOND 名に "Oblique" が含まれるようにし、2 種類の Light スタイルには "Light" が含まれるようにする。フォントの "Light" 版の変種を Mac スタイル で (何も選択されない状態にすることにより) Regular に設定し、"Light-Italic" の変種を "Italic" に編集する――これは、FOND が扱えない"Light" については忘れるということです。"Light" のついた物をそれ自体別のファミリーとして分類したのはそのためです。

この設定が終わったら、Macファミリーを出力(F) コマンドを実行すれば、すべてのフォントは適切な FOND に配置し、すべての FOND を Mac が正しく解釈できるはずの 1 個のファイルに出力することができるでしょう。

なぜ自作のフォントが ATM でうまく使えないのか?
フォントを出力する時には、それが Macintosh Latin エンコーディングを含んでいることを確認してください。

この制限事項は完全に ATM のせいであって、FontForge がこれに対して手出しできる事は何もありません。

もし、フォントを Macintosh Latin 以外のエンコーディングで出力した場合には、Mac のデフォルトの動作では、その PostScript フォントが Macintosh Latin 符号化方式を含んでいると強制的に解釈します。このふるまいを停止する機能が存在しますが、それを停止してしまうと ATM はまったく動かなくなるでしょう。

MS Windows でフォントを編集するにはどうすればよいか?
FontForge を MS Windows で実行するには、まず最初に cygwin の実行環境 をインストールしなければなりません。

あなたが cygwin 環境で FontForge をビルドできるようにしたいならば、gcc や画像処理ライブラリ、freetype などのいくつかの cygwin コンポーネントを取得する必要があるでしょう。

なぜ自作のフォントが Windowsで使えないのか?
ここに示すのは 1 つの可能性です: Windows は場合により (どんな場合かはよく分かりません)、適切な言語 (例えば、SJIS フォントでは日本語) の名前が name テーブルに含まれていることにこだわります。エレメント(L)→フォント情報(F)→[TTF名]を呼び出して、使用している言語の文字列を一式追加してみてください。

その他の可能性については ここで議論しました。

OTF または Type1 フォントを読み込んだ時、ほとんどすべての参照がインラインのコピーに置き換えられてしまう。元の参照を復元するにはどうすればいいか?
PostScript フォントを読み込んだときに、それにもとは参照が含まれていたのを認識するのは非常に困難です。その代わりに、FontForge にはフォント内に含まれる潜在的な参照の候補を検索してそれらを参照に置換する専用のコマンド 編集(E)→参照に置換 があります。
FontForge は元のカーニング情報をフォントから読み込むのか?
この質問はいくつかの場合に分けて答える必要があります:
TrueType および OpenType フォント
はい。カーニング情報は、これらの形式のフォントでは 'kern' または 'GPOS' テーブルに格納されており、FontForge はほとんどの一般的なフォーマットを読み込むことができます (Apple はオリジナルの TrueType の仕様に数々の拡張を加えていて、FontForge は Apple のフォーマットを完全にはサポートしていません)。
Mac 以外のあらゆる環境での PostScript Type1 フォント
カーニング情報は Type1 フォントファイルには格納されません。その代わりに、ファイル名の本体が同じで拡張子が ".afm" になっているファイルの中に格納されます。FontForge が PostScript フォントを読み込むとき、それは付随する AFM ファイルをチェックし、もし見つかったならば、そのファイルからカーニング情報を読み込みます。
Mac 上での PostScript Type1 フォント
いいえ。この場合もカーニング情報はフォントファイルの中には格納されません (それは、ビットマップフォントファイルの中に格納されます) が、Mac 上では付随するビットマップの名前を推測することが不可能なため、FontForge は試そうともしません。
FOND からカーニング情報をどのようにして読み込むかについては、下記の情報を参照してください。
AFM および TFM ファイル
FontForge はカーニング情報をこれらのファイルから直接読み込み、それらのデータをフォントに対して適用することができます。ファイル(F)→カーニング情報の併合 メニューコマンドを参照してください。
FOND リソースを含む Mac リソースファイル
Mac はカーニング情報をビットマップフォントに伴う FOND リソースに格納します。これは PostScript フォントを含むファイルには格納されていません)。Mac の PostScript フォントにカーニングデータが必要な場合、PostScript フォントと同じファミリーとスタイルをもつビットマップフォントを含んだフォントファイルを見つけなければなりません。FontForge はカーニング情報を直接これらのファイルから読み込み、そのデータをフォントに適用することができます。ファイル(F)→カーニング情報の併合 メニューコマンドを参照してください。
これは簡単です。既存のフォントを開き、次に エレメント(L)→フォントを出力(G) コマンドを使って欲しいファイル形式で出力してください。
あるビットマップフォーマットから他の方式に変換するにはどうすればよいか?
これも簡単です。ビットマップフォントを開き、次に エレメント(L)→フォントを出力(G) コマンドを使って欲しいファイル形式で出力してください。
アウトラインフォーマットからビットマップフォーマットに変換するにはどうすればよいか?
アウトラインフォントを開いてください。次に エレメント(L)→使用するビットマップ(A) を使って、適切なサイズのビットマップを (必要なだけ) 生成してください。この処理はラスタ変換と呼ばれ、小さなサイズの場合計算機ではうまく行うのが困難です。ラスタ変換の結果をビットマップウィンドウ内で (ウィンドウ(W)→ビットマップウィンドウを開く(B)を使って) 確認すれば、おそらくビットマップを望み通りに修正する必要があるだろうとアドバイスしておきましょう。それが終ってからファイル(F)→フォントを出力(G)を選択し、アウトラインフォントの出力をオフにして (もちろん、アウトラインフォントが必要な場合は別です)、必要なビットマップフォーマットを選んでください。
ビットマップフォーマットからアウトラインフォーマットに変換するにはどうすればよいか?
非常に大きなビットマップフォント (TeX フォントのような) を持っているのでなければ、以下の処理によって良好な出力結果は得られないでしょう。
FontForge がヒント置換を行うようにするにはどうすればいいか?
勝手に処理してくれます。
FontForge が flex ヒントを使うようにするにはどうすればいいか?
勝手に処理してくれます。FontForge は flex ヒントを出力するのが適切な状況のときに出力を行います。あなたは何もする必要はありません。flex ヒントを使用するとき、必要なサブルーチンはフォントに追加されます。ヒントが不要な時は、サブルーチンは追加されません。
flex ヒントが使われるかどうかはどうすれば分かるのか?
FontForge が flex ヒントを使おうとしているかどうか確認したいときは、環境設定項目 UpdateFlex をオンにしてから当該グリフのグリフビューを開いてください。FontForge は、flex ヒントの中心点を緑色の丸で囲って示します。
どのグリフも完璧にヒントづけしたのに、幅が揃わない (またはぼやけて見えたり完全に掠れて見えなかったりする) ステムがあるのはなぜか?
PostScript と TrueType のどちらも、グリフの輪郭は時計回りに描かなければなりません。あるラスタライザではどちらでも問題になりません。しかし別のラスタライザでは反時計回りのパスを描いたときに、正しい幅と異なる太さのステムや、ぼやけたステムを表示したり、全く何も表示しないことさえあります。これに対する解決策は、フォントを出力する前に、エレメント(L)→アウトラインの向きを修正(C) を全ての文字に対して実行することです。
OS/2 テーブル (または別のどれか) の特定のビットをセットするにはどうすればいいか?
FontForge はその機能はありませんが、私は mensis (ラテン語で「テーブルに(のために,によって,から)」の意味) というテーブルにビット単位のアクセスができる補助プログラムを書きました。これは UI とスクリプトアクセスの両方を提供しています。
フォントを等幅であると設定するにはどうすればいいのか?
それはできません。フォント内の全てのグリフが同じ幅を持つようにすれば、FontForge はそれを等幅であると印づけます。(実際に等幅でないフォントを等幅と印づけると、一部のラスタライザでは結果がおかしくなります)。

フォントに含まれる全グリフが同じ送り幅を持っているかどうか自信がない場合は、エレメント(L)→問題点を発見(O)→[ランダム]→送り幅をチェック: を使用してください。

FontForge に新しいエンコーディングを追加するにはどうすればいいか?
本当に新しいエンコーディングが必要ですか? 自問してみてください。OpenType または TrueType フォントを使用しているなら、標準の Unicode エンコーディングで用が足りるはずです。しかし、もし本当に新しく追加する必要がある場合、必要な作業は大体こういう感じです:

似たようなエンコーディングを探す。しばしば、そのエンコーディングの雛形となるものを探して Web を検索して回る必要があります。例えば、デーヴァナーガリー文字のエンコーディングが必要なら、ISCII の各種エンコーディングを載せているサイトを参照するべきでしょう。

これらのエンコーディングは上半分の 96 文字のみを示しています。おそらく、他は US ASCII と同じでしょう。画像を見てそれらが Unicode にどのように対応づけられるか (または、より正確にやるならば、それらの文字の適切な PostScript 名はなにか) を調べてください。

ファイルを作成します (この例では "Devanagari.ps" と呼ぶことにします)。それはこのような行で始まるでしょう:

/Devanagari {

これは FontForge に、このエンコーディングが "Devanagari" という名前であることを指示しており、その後ろにはすべての文字の (スラッシュが頭についた) 名前のリストが続きます。最初は ASCII で、32 個の .notdef 文字から始まり、それから space 等の文字が続きます。

/Devanagari {
 /.notdef
 /.notdef
 ...
 /.notdef
 /space
 /exclam
 /quotedbl
 ...
 /braceright
 /asciitilde
 /.notdef
 ...
 /.notdef
 /uni0901
 /uni0902
 ...
 /uni096F
}

ファイルを作成したら、FontForge のエンコーディングリストに エレメント(L)→フォント情報(F)→エンコーディング→[読み込み(L)] でこれを追加し、それからお好きなフォントにそれを適用してください。

新しい名前のグリフを追加するにはどうすればいいか?
ここでは仮に、グリフ "dotlessi" を ISO 8859-1 のフォントに (これには dotlessi は含まれていません) を追加したいとしましょう。この問題へアプローチする方法は 2 つあります:
  1. エレメント(L)→フォント情報(F) を呼び出す
    エンコーディング タブを選択する
    グリフの数(N) フィールドを 1 増やす (おそらく 257 になるでしょう)
    OKを押す
    フォントの最後までスクロールして新しいグリフを探す
    そのグリフを選択する
    エレメント(L)→グリフ情報(I) を呼び出す
    新しい文字の名前を Unicode名(N) フィールドに入力する (この場合は dotlessi と打つ)
    名前で指定(A) ボタンを押す
    OKを押す
    これで、そのグリフに dotlessi をデザインすることができます。
  2. エレメント(L)→フォント情報(F) を呼び出す
    エンコーディング タブを選択する
    エンコーディング(E) から ISO 10646-1 (Unicode, BMP) を選択する
    OKを押す
    表示(V)→移動(G) を呼び出す
    dotlessi と打ち込む
    OKを押す
    ここで、選択されたグリフスロットにグリフ dotlessi を作成する
    もう一度エレメント(L)→フォント情報(F) を呼び出す
    エンコーディング(E) を変更前の値に戻す
自作の OpenType フォントが .pfb ファイルよりもずっと小さくならないのはなぜか?
それはおそらく、フォントを出力する前に座標値を整数に丸めていないからです。FontForge は、通常の整数よりも遥かに大きな容量を必要とする固定小数点数としてフォントを出力します。
OpenType と PostScript (や TrueType) フォントはどこが違うのか?
PostScript フォントと TrueType はそれぞれ独自のファイルフォーマットとグリフフォーマットの定義をもっています。OpenType は TrueType のファイルフォーマットを PostScript のグリフフォーマットと組み合わせて使います (実際には、OpenType には TrueType グリフフォーマットの物も含まれますが、OpenType の定義書ではそのようなフォントは現在でも TrueType フォントと呼ぶ (訳註: 拡張子 .otf ではなく .ttf を使う) べきであるとしていますので、この点については無視することにします)。

OpenType で使われている PostScript のグリフフォーマットは、.pfa および .pfb ファイルで使用されている物とはわずかな違いがあります。pfa/b ファイルで使用されているのは Type1 フォントであり、OpenType では Type2 フォントを使用します。Type2 は Type1 のほとんど完全なスーパーセットで、わずかな変更点と多数の拡張を Type1 に加えたものです。Adobe による、Type1 へのサブルーチンをベースとした拡張 (flex ヒント、ヒント置換、カウンタヒント) は、Type2 では直接命令として追加されています。

フォントを生成した後に終了しようとすると、フォントを保存するかどうか FontForge が訊いてくるのはなぜか? 私は何も変更していないのに。
なぜこういう事が起こることがあるのかには、2 つの理由があります。
  1. このセッションでは何もいじっていないにしても、FontForge は 1 個または数個のグリフのヒント情報を(再)生成する必要があることがあります (例えば、それらのグリフが (以前のセッションで) 変更されたが、その時以来ヒントが生成されていない場合に)。これらのヒント更新により、フォントに変更ありの印がつけられます。
  2. 開いたフォントの フォント情報 の XUID フィールドが定義されているときは、FontForge は PostScript フォントが出力されるごとに XUID を 1 ずつ増やします。そして、これも変更の 1 つであると勘定されます。(FontForge はなぜこれを行うのでしょう? Adobe がそうするべきだと言っているからです。少し煩わしいことではありますが、古いバージョンのフォントを新しい物に置き換えた時に、フォントキャッシュに関する問題が起こるのを避けることができます)。
自作のフォントが TeX で使えないのはなぜか?-->
私は TeX に関しては完全に初心者です。私が聞いたところでは、TeX (または TeX 処理の連鎖のどこか、おそらく dvips) は、フォントは TeX Base エンコーディングで符号化されていると仮定しています―― TeX の文書では "Adobe Standard" と呼んでいるものもたまにありますが、それは TeX Base とは異なります。ですから、印刷時に出ない文字があるなどの問題があるのでしたら、フォントのエンコーディングを TeX Base に変更してみてください (エレメント(L)→フォント情報(F) を呼び出し、エンコーディング タブを選択し、TeX Base をプルダウンリストから選択してください)。
FontForge で '.mf' ファイルを編集できないのはなぜか?
Knuth が言ったように (訳註: Brian Kernighan だとする人もいる)、「(WYSIWYG の問題点は)、見えている物が手に入るすべてだということです。FontForge はこの制約に苦しめられています。

単純な例を示すことにしましょう。ある点が以下の数式で指定されているとします:
     top1y2 = CapHeight
それで、ユーザが点 2 を垂直方向に移動して、y 座標を新しい値に変更したとします。FontForge はこれをどう解釈するべきでしょうか? 以下の可能性が考えられます:

FontForge で点を移動する方法はこれほどまでに意味づけが曖昧なのです。そのうえ、曖昧さを取り除くための納得のいく方法は何も見つかっていません。提案があれば歓迎します (ただし、それらの方法を私が実装する保証はまったくありません)。

ビューを縮小しようとすると、ウィンドウがアイコン化されてしまうのはなぜか?
いくつかのウィンドウマネージャ (gnome-sawtooth はその 1 つです) は、Meta (Alt) キーつきのクリックを FontForge から奪ってしまいます。そのため、グリフを縮小するのに Meta-中クリック を使うことはできず、メニューコマンド 表示(V)→縮小(O) を使用しなければなりません。
作成したギリシャ語フォントに "mu" という名前の文字が見当たらないのはなぜか?
Adobe は、Unicode エンコーディングでギリシャ文字に名前をつけるときに、意味よりも後方互換性の方が重要であると考えました。それが原因で、"mu" はマイクロ記号 (U+00B5) を参照していて、ギリシャ文字ミュー小文字ではないのです。他にも、彼らは "Delta" を増分記号に、"Omega" をオーム記号に割り当てています。

また、Adobe はかつて U+03D6 (Unicode コンソーシアムにより、"GREEK PI SYMBOL" を指すと言明されています) を "omega1" と呼ぶことに決めています (これは "pi1" のほうがずっと適切だと思うのですが)。

編集(E)→コピー(C) で、グリフ情報と一緒にグリフ名がコピーされないのはなぜか?
最初の理由として、グリフ名をコピーしようとする人がやりたい事は、カスタムエンコーディングを定義したほうがうまくできることがほぼ確実だからです。
2 番目の理由は、誰でもほとんどの場合は名前をコピーしたくないだろうからです。
3 番目の理由は、コピーはデータのみに作用し、メタデータには作用しない方が美的に優れているからです。
し か し な が ら……この質問をする人が多いので、私はそれに負けて編集(E)→コピー元の指定(C)→グリフのメタデータ(M) でデフォルトの振舞を変更できるようなモードを作成しました。
編集(E)→貼り付け(P) を行うと、名前が重複していると怒られるのはなぜか?
編集(E)→コピー元の指定(C)→グリフのメタデータ(M) にチェックが入っているとそうなります。チェックを外してください。
cidmap ファイルって一体全体何のこと、知らないと何かまずいことがある?
いくつかの背景的事情を説明します:

PostScript が考案された時は、フォント内の全てのグリフに名前がついていて、256 要素の配列によって指定されるエンコーディングが、文字コードから名前への対応づけを行っていました。

その後で、巨大なグリフセットをもつ CJK フォント (それとおそらく Unicode) について彼らが考え始め、10,000 個のグリフに納得のいく名前を ASCII でつけるのは a) スペースの無駄使いで、b) まったく意味が無い、という結論に達しました。そういうわけで、その時 Adobe は、グリフ名もエンコーディングも含まれていない CID キー指定フォントを発明しました。

Adobe は、いくつかの標準 CMap リソースを提供しています (例えば、SJIS 用のもの、 JIS 用のもの、各国語の EUC 用のものなど)。これらのファイルを書くのはとても面倒な作業なので、Adobe は各 CID に標準の意味を与え、誰もが同じ CMap ファイルを使えるようにしました。――えー実際には 5, 6 種類の異なる標準がありまして、日本語 (JIS X 0208), 日本語 (JIS X 0212), 韓国語、中国語 (香港・台湾)、中国語 (本土・シンガポール)、Identity (Unicode) などです――それで CID 1 は空白、 CID 2 は "!", CID 985 は「カ」のように決まっています。

私の作った cidmap ファイルは、Adobe の CID と Unicode の対応関係を示すだけのものです。これにより、どういうグリフに大して作業を行っているかを FontForge が知ることができます。これが無くても動作に問題はありませんが、FontForge はフォントビューに適切なグリフではなく "?" を表示するでしょう。また、FontForge はフォントを Unicode やその他の方式に符号化しなおすことはできないでしょう。

要するに、cidmap ファイルが役に立つのは、CJK の CID フォントの作業を行う人だけです。

単純化(S) コマンドを使うと文字の正確度が落ちるのか?
はい、落ちます。
でもさほど落ちません。
このコマンドは、連続した複数スプラインを、オリジナルからローカル座標系で 1 ユニット以内のずれの範囲内で近似する 1 本のスプラインで置き換えます。
もしこのレベルの精度では不十分な場合、(アウトラインビューで)

という手順で操作を行うと、連続したスプラインは、オリジナルから 0.1 ユニット以上ずれることのないスプラインで置き換えられます。

FontForge では、どうやって 3 次スプラインを TrueType で用いられる 2 次スプラインに変換しているのか?
この場合も、正確度の低下が伴います。
最初に、FontForge はスプラインがちょうど 2 次曲線で表せるかどうかチェックします (これは、スプラインが TrueType から読み込んだそのままである場合か、またはスプラインを出力するときに奇跡的な偶然によって起こります)。
2 次曲線で表せない場合は、FontForge はオリジナルの曲線を小さな塊に分割し、元の 3 次スプラインからどこも 1 ユニット以内の違いしかない 2 次スプラインの列を見つけようとします。(2 個の端点を選択して、それらの端点における傾きが判明していれば、それらの端点の間に可能な 2 次スプラインは 1 個しかありません)。
FontForge は (TrueType を読み込む際に) どのようにして 2 次スプラインを 3 次に変換しているのか?
任意の 2 次スプラインは、3 次の項が常に 0 になっているだけと考えれば、既に 3 次式で表されているものとして扱うことができるので簡単です。
フォントのデフォルトグリフを設定するにはどうすればいいか?
符号位置 0 にあるグリフが ".notdef" という名前で、そこに何らかのスプラインが含まれていれば (ただし参照がない場合に限り) そのグリフはデフォルトグリフとして扱われます (".notdef" というのは、符号化されていないグリフのために用いられる名前です)。
TTF フォントを読み込んで、2,3 箇所修正してから新しいフォントを出力した。変更したグリフはどこから見てもオリジナルと比べて見劣りする。なぜか?
残念ながら FontForge は TrueType フォントにヒントづけを行うのがまったく上手ではありません。ですから、FontForge が TrueType フォントを読み込んだ時には、オリジナルのフォントに含まれていた全てのヒント情報 (命令) を保持します。しかし、あるグリフに変更を行ってしまうとそれらの命令はもはや正しくありません (それらはアウトラインの細部に密接に依存しています) ので、変更を行った時点で FontForge はそれらを削除します。その結果、ほとんどの TrueType フォントでは、グリフを FontForge で変更するとその見栄えが悪化することになります (全てではありません。ヒントの無いものもいくつかあります)。 FontForge は垂直・水平方向のステムにはヒントをつけることができますが、斜めのステムにはヒントづけできません。FontForge のヒントづけの試みによって、 (斜めのステムが水平・垂直と整合しなくなって) グリフの品質がかえって悪くなることも珍しくありません。そういうわけで、ヒントづけをしてほしい場合には、ヒント(H)→ヒント命令の自動生成(I) をあからさまに呼び出さなければなりません。 OpenType フォントを生成したが、Windows にはインストールできない。なぜできないのか?
残念なことに、Apple と Microsoft (および Adobe) の間では、OpenType および TrueType の正しいフォントフォーマットについて合意がとれていないのです。FontForge は、フォント出力ダイアログに [] Appleの仕様 と書かれたダイアログを用意しています。Mac 用のフォントを出力するときには、忘れずにこれにチェックを入れてください。Windows 用の (おそらく Unix も同じです。通例 Unix はさほど気難しくありませんが) フォントを出力するときには、チェックを外すことを忘れないでください。

私が今までにつまづいた大きな違いをすべて以下に挙げます:

kaiu.ttf や mingliu.ttf を開いてみると、アウトラインは正しいグリフと全然違って見える。何がまずいのか?
ある種の TrueType フォント (kaiu と mingliu) は、正しいアウトラインを格納していません。その代わり、それらはアウトラインを生成するのに、点の位置を移動する命令に依存しています。アウトラインは全くグリッド合わせは行われず、ただ位置指定がされるだけです。FontForge はフォントを読み込んだときに命令を処理しません。ほとんどのフォントではこれは行うべきではないでしょうし、それを行うべき時を判別するにはどうすればいいか分からないからです……。
ギリシャ文字拡張 (U+1F00〜U+1FFF) のグリフを作るために エレメント(L)→アクセントつきグリフを構築(B) を使用すると、FontForge は間違ったグリフを選ぶのはなぜか?
いくつかの理由により、Unicode はギリシャ文字とラテン文字のアクセントを、それらが全然違って見えるときでも統合してしまっています。FontForge が単純な Unicode の定義にしたがった時には、ギリシャ文字のグリフに対してラテン文字用のアクセントを組み合わせてしまうでしょう。好運なことに、Unicode はギリシャ文字のアクセントに適切なコードポイントも、U+1FBD から始まる位置に用意しているので、それらのコードポイントに正しい形のアクセントを作れば、FontForge はラテン文字のアクセントよりそちらを優先して使用します。
"u" や "y" の上にアクセントをつけるために エレメント(L)→アクセントつきグリフを構築(B) を使用すると、アクセントがどちらかのステムの真上に来てしまい、グリフの中央に来ないのはなぜか?
それらのステムの片方が、もう片方よりわずかに高いせいです。FontForge はアクセントをグリフの最も高い点の上に配置します。同じ高さの点が複数あるときは、それらの平均が用いられます。

全てのステムの高さを同じに揃えれば、アクセントは正しく中央に配置されるでしょう。

FontForge が出力した TTF ファイルを処理すると ttf2afm がクラッシュするのはなぜか?
私は知りません。RedHat 7.3 Linux に入っている ttf2afm はおそらく確実にクラッシュするでしょう。ソースを CTAN の pdftex の置き場所からダウンロードして (デバッグ機能つきで) ビルドしたら、できたプログラムはクラッシュしませんでした。
だから、これは ttf2afm のバグで、既に修正されているに違いないと思います。
ttf2afm によって出力された AFM ファイルは、Adobe の仕様に適合していません。
なぜ FontForge はとても不安定なのか?
私は品質保証にあまり手間をかけていないのです。これは問題ありです。私はそれが楽しくないし、それをするように私に給料を払う人は誰もいないので、ほとんど行われていないわけです。
あなたが品質保証の作業を志願するならば、私にお知らせください。感謝されない仕事ですが、とても大事です!

-- -- 目次 -- --