- ラテン文字のフォントはたくさんあります。それに比べて、ギリシャ文字・キリル文字・インド系文字・タイ語・中国語・日本語・韓国語・Unicode のフォントはずっと少ない…。
- 古い書字システムの研究者は、自分自身のフォントをデザインしなければならない場合がよくあります。
- ラテン文字ですら、伝統的には芸術や建築に新しいスタイルが生まれるごとにそれに伴う書体のスタイルが新しく作られました。現代では、時代の美意識を反映するために常に新しいフォントが作られています。
- コンピュータフォント技術は常に変化しています。10 年前に有用であったフォントフォーマットは現在役に立ちません。
-
あなたが既存のフォントに満足だったとしても、それが完全でない可能性はあります。
- 不足の合字
- 不足のアクセントつき文字
- それに合うキリル文字又はギリシャ文字のグリフ
- 誰もが、自分自身の手書き文字をフォントにしたいと思います。
- フォントで遊ぶのはとても楽しい。
FontForge は単にフォントを作成・編集するだけではない用途にも使えます。あるフォーマットから他のフォーマットに変換することができます。フォントファイルから情報を取り出すこともできます。または、フォントをインストールしないで、それがどのように見えるかを表示するだけのために使うこともできます。
- それが楽しいから。
- MacroMedia が Fontgrapher の開発をやめてしまったから。それと、Fontgrapher には、私が欲しかった機能がなかったから。
- 私はフリーソフトウェアに賛成していて、良い製品が良いオペレーティングシステム上で得られることにより、人々が商用のオペレーティングシステムを使わないことを奨励するから。
- プログラミングはマーケティングよりもずっと楽しいし、人にあげてしまう方が売るよりも簡単だから。
- これを売ることにすると、品質保証のために大量の時間を使わなければならないから。
それと、私はチェックボックスがチェックされているかチェックされていないかが本当に見分けられるウィジェットセットが欲しかったのです。私の目にはどっちがどっちだか区別のつかない場合が多すぎたもので…。
基本的に、私はオブジェクト指向を実践することがほとんどの場合に役立たずであると考えているからで、それに加えて、私は C++ があまりに複雑で悪いデザインであると考えているうえに、私はそれを簡単にデバッグできないからです。
- 私は SIMULA で育ち、SmallTalk をかじったことがある人間ですが、何年かの経験の後に、オブジェクト指向アプローチが私にとって自然に感じるような問題は非常に少ないことを悟りました。ほとんどの場合、それは単に不要な複雑さを解くべき問題に持ち込んでいるだけのように見えたのです。
- C++ プログラムのセマンティクスは仕様化することが不可能です。コンパイラは、必要だと判断したときに思いのままにテンポラリを生成することができますが、C++ ではテンポラリを作成すると、予期せぬ副作用を伴う可能性のあるコンストラクタとデストラクタの呼び出しを引き起こします。私はこれにはぞっとしますね。
- 外部コンストラクタの実行順序が指定されていません。これによって説明不可能なバグがたくさん発生するのを私は経験しました。
- 私は、C++ のデバッグが非常に難しいことに気づきました。1 個の文をステップ実行すると、予想しない手続き呼び出しがたくさん発生することがしばしばです (それらの一部は、自明ではインライン関数です)。これにより、デバッグの元来の目的から気が散らされます。
-
もう一つ言えば、言語の仕様化がへたくそで複雑すぎると思います。その各種の概念は相互にうまく整合していません。各コンパイラはそれぞれ異なる形で処理を行っているような気がします。
私は 1981 年頃に、当時 "C with Classes" と招ばれていた C++ に出会いました。私は 1987 年から 1994 年にかけて、Green Hills Software のコンパイラスイートのために C++ フロントエンドを書き、バージョン 1.1 から ANSI までのそれぞれの新バージョンを追跡してきました。
どのバージョンにも、以前のものの上にうまく追加できない新機能がありました。どのバージョンも仕様は不完全でした。参照実装は標準とはむちゃくちゃに違っていました。例えば、コンストラクタ内の仮想関数のふるまいは言語のバージョン 2 まで規定されておらず、その規定が素朴な解釈と異なっていたためにバグが発生しました。私のお気に入りの混乱は、(私の記憶が確かならば) バージョン 2.1 の仕様で、あるページの 2,3 段落の内に、以下の 2 つの文が飛び出したことです: "共用体はメンバ関数を含むことができる" と、"共用体はメンバ関数を含むことができない"。
上に書いたのは私の個人的な経験に基づいた個人的な意見で、なぜ私が C++ を使わないかの説明です。あなたの意見はこれとは違うでしょう、C++ コンパイラを書くのに 5 年間を費した人はほとんどいませんから。
あなたがフォントとともに入手した使用許諾を見て、この件に関してそれには何と書かれているかを見てください。
TrueType (および OpenType 並びに潜在的には CID キー指定フォント) には、OS/2 テーブル内に FSType と呼ばれるフィールドがあり、そこには他の人がこのフォントに対して何をすることができるかについてフォントデザイナーが制限を課すことができます。もしこのフィールドが変更を禁止している場合、FontForge は、あなたがフォントデザイナーからこのフィールドの制限を無視することの合意を得ているかどうかを尋ねます。
米国の法律についての私の理解するところは以下のとおりです (ただし、これに頼る前に弁護士のチェックを得てください):
- フォントデザインに対する法的な保護は存在しない。それゆえ、米国内ではグリフ画像を合法にトレースすることができる。フォントデザイナーが現在生きている場合、これは明らかに倫理上の問題がある。
- フォントプログラム (PostScript または TrueType のフォントファイルといったもの。ただしビットマップフォントファイルはこれに入らない) は著作権で保護可能である。
- フォント名は商標権で保護することができる。
私の理解では、ほとんどのヨーロッパの国々では、フォントのデザイン (形) を複製することを禁ずる法律が存在します。
追加、または訂正があれば歓迎します。その他の国でフォントに関する規定のある法律についてに情報も歓迎します。
あるフォントが 12 ポイントの高さをもつのは、(ベタ組みの) テキストで隣接する 2 行のベースライン同士の間隔が 12 ポイントである時です。
ポイントサイズは、フォントのどのグリフのサイズにも基づいていません。
フォントが金属で作られていた時代に戻ると、フォントのポイントサイズは、そのフォントとともに用いられていた込物の高さと同じでした。
ある意味ではこれはフォントのサイズの計り方としてあまりいい方法ではありません (いくつかのフォントはアクセントまたはアセンダやディセンダに他のフォントより多くの空間を取っているため、実際のグリフの高さはより小さくなることになります)。
グリフの x ハイトに基づいた計測体系もあります。
英米ではポイントとは伝統的にパイカポイント (1 インチの 72.27 分の 1) のことでしたが、ヨーロッパではポイントはディドーポイント (1 インチの 67.54 分の 1) のことでした。ヨーロッパではわずかに大きなポイントを使用していますが、英国とヨーロッパのフォントは同じサイズであることが分かっています。ほとんどのヨーロッパの諸言語ではアクセントを使うのに対して、英語では (ごく稀な場合を除いて) アクセントを使用しないので、ポイントのサイズがわずかに増えたことによってアクセントのための空間がより多く取ることができます。
(もちろん、現在ではほとんどのヨーロッパ人はデスクトップソフトウェア上でパイカポイントを使うことを強いられており、ほとんどのコンピュータフォントは現在アクセントつきグリフを含んでいます。ですからこれらの区別とその必然性は消え去ったと言えるでしょう)。
- Type 1 フォントでは、行間を設定する方法はありません。たいていの場合、アプリケーションはフォントのバウンディングボックスで指定された値を行間の設定に用います。これは彼らの側にしてみればまったくひどい考えですが、広く実践されている方法です。
-
TrueType/OpenType フォントでは答えは非常に複雑です。
-
Mac では
ラインスペーシングは 'hhea' テーブルのアセンダとディセンダの値によって設定されます。これは、裏を返せばフォントのバウンディングボックスの値に設定されるということです。これは賢い選択ではありません。 -
Windows では
ラインスペーシングは OS/2 テーブルの Typo Ascent/ Typo Descent の値により設定されるものとされています。その一方、これらは EM サイズと一致するものと仮定されています。(FontForge はこれらの値を、ユーザがフォントに対して設定した高さ(A)/深さ(D)の値にします)。これらの値は、フォントのクリッピング領域 (ラインスペーシングではなく) を指定するものと考えられます。クリッピング領域はフォントのバウンディングボックスを含む大きさであるべきですが、ある場合にはそれより大きくする必要があります。(GPOS の位置指定によってグリフがバウンディングボックスからはみ出る位置に移動する場合は、クリッピング領域はバウンディングボックスよりも大きくする必要があります (マークから基底文字への参照が問題を起こすようです)。GPOS によって行がいくらでも高くなる可能性があるウルドゥー語の筆記体ではこれがどのように当てはまるのかについてはよく分かりません)
-
Linux では
一般的な合意が存在するのかどうかは知りません。アプリケーションはおそらく上記の方法のいずれかを使用するでしょう。
-
Mac では
- 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 が出力したフォントは 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 のフォントを編集する手順は以下のようになります:- System Folder:Fonts フォルダにあるファイルを見つける
-
ファイルを Unix マシンにコピーする
- Fetch を使用し、MacBinary フォーマットを指定する。
- または BinHex のような、ファイルを直接作成できるツールを使う
- それを FontForge で開く
- 編集する
- フォントを再び MacBinary フォーマットで保存する
-
それを Mac に返送する
- Fetch は自動的に MacBinary ラッパを展開し、正しいファイルにします
- またはその他各種のツールでも展開できます。
- それを元のシステムフォルダにドロップする (それにより、自動的に 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 リソースを出力する何らかのデータを書き出すようにする予定はありません――その他のも同様にありません)。
同じファミリーに含まれるフォントには、すべて同じファミリー名をつけなければなりません (フォント情報ダイアログを参照してください)。フォントファミリーは Carbon (OS 9 で使われていた古いフォント処理メカニズム) と、(OS X の) ATSUI とでは扱いがかなり異なります。
Carbon では、フォントファミリーが使えるのは、1980 年台前半のコンピュータフォント技術を反映している、Mac の "FOND" リソースに限られています。現代的なコンピュータフォントは、これでは表しきれない変種を含むことがしばしばあります。FONDS は以下のスタイルの任意の組合せをサポートします (ただし Extend と Condense は同時に指定できません):
- Bold
- Italic
- Condense
- Extend
- Underline
- Shadow
- Outline
Mac の FOND は "Black", "DemiBold", "Light", "Thin" または "Extra-Condensed" のような変種をサポートしていません。
一方、ATSUI の下では、ファミリーは同じ FamilyName をもつ一定のリソースファイルに含まれるすべてのフォントから構成されているようです。
以下のスタイルをもつフォントのファミリーがあるものとする:
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 のせいであって、FontForge がこれに対して手出しできる事は何もありません。
もし、フォントを Macintosh Latin 以外のエンコーディングで出力した場合には、Mac のデフォルトの動作では、その PostScript フォントが Macintosh Latin 符号化方式を含んでいると強制的に解釈します。このふるまいを停止する機能が存在しますが、それを停止してしまうと ATM はまったく動かなくなるでしょう。
その他の可能性については ここで議論しました。
- 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)→カーニング情報の併合 メニューコマンドを参照してください。
-
何か処理を行う前に、potrace か autotrace プログラムがシステムにインストールされているか確認してください。
- 新しいフォントを作成します。
-
ファイル(F)→取り込み(I)コマンドを使って、ビットマップフォントをこの新しいフォントに取り込みます。
-
[] 背景として使用チェックボックスにチェックが入っているか確認してください。
-
- 編集(E)→すべて選択(A)
- エレメント(L)→自動トレース(R)
- エレメント(L)→極大点の追加(X)
-
エレメント(L)→単純化(S)
おそらくこの段階で、アウトライングリフを目で見て形を整える必要があるでしょう。 - ファイル(F)→フォントを出力(G)
フォントに含まれる全グリフが同じ送り幅を持っているかどうか自信がない場合は、エレメント(L)→問題点を発見(O)→[ランダム]→送り幅をチェック: を使用してください。
"全グリフ" とここで言ったのは本当に全てのグリフのことです。Unicode の規格が幅 0 であると定めている文字ですら、その他全てと同じ幅でなければなりません。Microsoft は、アクセントの組合せ (等) を行うのに GPOS を使用し、任意のマーク (アクセント) の幅を 0 に変更することを提唱しています。
似たようなエンコーディングを探す。しばしば、そのエンコーディングの雛形となるものを探して 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)] でこれを追加し、それからお好きなフォントにそれを適用してください。
-
エレメント(L)→フォント情報(F)を呼び出す
エンコーディングタブを選択する
グリフの数(N)フィールドを 1 増やす (おそらく257になるでしょう)
OKを押す
フォントの最後までスクロールして新しいグリフを探す
そのグリフを選択する
エレメント(L)→グリフ情報(I)を呼び出す
新しい文字の名前をUnicode名(N)フィールドに入力する (この場合はdotlessiと打つ)
名前で指定(A)ボタンを押す
OKを押す
これで、そのグリフに dotlessi をデザインすることができます。 -
エレメント(L)→フォント情報(F)を呼び出す
エンコーディングタブを選択する
エンコーディング(E)からISO 10646-1 (Unicode, BMP)を選択する
OKを押す
表示(V)→移動(G)を呼び出す
dotlessiと打ち込む
OKを押す
ここで、選択されたグリフスロットにグリフ dotlessi を作成する
もう一度エレメント(L)→フォント情報(F)を呼び出す
エンコーディング(E)を変更前の値に戻す