2017年4月28日
※記載している内容はGlyphs 2.4.1 (983)を使用して確認しました。他のバージョンでは結果が異なるかもしれません。個人の限られた環境で独自に確認しているため他の環境では結果が異なる可能性もあります。また、筆者の知識不足などにより内容に誤りがあるかもしれません。この点を了承のうえお読みください。
Adobe-Japan1-6フォントを作成する過程で発生する問題や注意点を見つけるために行いました。グリフの編集に関する確認ではなく、フォントの出力に関する確認を行っています。
Adobe-Japan1-6で決められているグリフを全て作成するのはとても時間と手間がかかるので、今回はダミーのグリフを使って行いました。各グリフにはAdobe-Japan1-6で定められた字形ではなく、CID番号を表す5桁の数字を表すアウトラインパスを作成しています。詳細は後述の「４．作成したGlyphsファイル」を参照してください。
３．結果
このフォントを作成して分かったことを以下に記載します。
※以下に記載した内容にはGlyphs上の設定だけでは解決できない問題がありました。これはあくまでも筆者が解決できなかっただけであり、これらの問題は筆者の知識が不足しているために解決できないだけかもしれません。また、記載している内容ば筆者の独自解釈によるものであり、Glyphsアプリケーションの開発元から回答を得て記載しているものではありません。
3つのグリフ「space」「enspace」「space.half」が同時に存在している状態でフィーチャーを自動生成するとhwidでエラーが発生します。
エラーメッセージの「feature:」以降は変わる可能性があります。このエラーは自動生成されたhwidの中に「space」に対する定義が2つ存在していることが原因です。
この問題はhwidを手動で編集することで解決します。このとき自動生成されたhwidの中には「sub space by enspace;」と「sub space by space.half;」の2つ行が存在するはずなのでどちらか1つを削除すると解決します。Adobe-Japan1-xフォントの場合は「sub space by space.half;」を削除したほうが良いでしょう。
Adobe-Japan1-3以降の一般的なフォントはvrt2フィーチャーの中にローマングリフ等を時計回りに90度回転したグリフに置き換えるための情報を含んでいます。
Glyphs ハンドブック 2.3ではvrt2用のグリフ名に「.vertical」か「.vert」または「Vertical」を付けるように説明していますが、Adobe-Japan1-xフォントを出力する場合は回転したグリフに対して名前の後ろに「.rotat」を付けないと出力したグリフが適切なCID番号に割り当てられないようです。
このことから、例えばグリフ「A」のvrt2用として「A.rotat」を作成することになりますが、この状態でフィーチャーを自動生成しても「A.rotat」に置き換えるための情報がvrt2の中に自動生成されません。
Adobe-Japan1-xフォントのvrt2フィーチャーについては手動で編集するなどの対処が必要なようです。
※Glyphs ハンドブック 2.3ではrotatについて説明されていません。このブログで説明しているrotatに関する内容はあくまでも筆者の独自解釈によるものであり、将来利用できなくなることも考えられます。
Glyphsハンドブック 2.3ではvrt2フィーチャーの説明として「縦書き時に表示される回転字形のオルタネートです」とありますが、Adobe-Japan1-3以降のフォントには回転していない縦書き用グリフも含みます。
vrt2に含めた縦書き用グリフの高さは、自動的に対となる横書き用グリフの幅と同じ値に設定されます。この処理はGlyphsの内部にプラグインとして実装されているmakeotfGlyphsコマンド（AFDKOのmakeotfに相当するもの）によって行われているようです。
ローマングリフのように縦書き時に回転するグリフや、幅と高さが全角と決められているグリフについては問題はありませんが、プロポーショナル仮名のようにこの条件から外れるグリフについては注意が必要です。
例えばプロポーショナル仮名の場合は「横書き用の文字幅＝縦書き用の高さ」でないケースが多いはずです。このケースでは「横書き用の文字幅＝縦書き用の高さ」とみなして処理することができないので縦書き用グリフの高さを個別に設定する必要があります。
グリフの高さはGlyphsの画面上で設定できます。
例えば以下のように横書き用のプロポーショナル仮名に対して縦書き用のプロポーショナル仮名を作成した場合は期待通りの結果が得られます。以下の例では横書き用の文字幅は685、縦書き用グリフの高さは980に設定しています。
しかし、以下の例では期待通りの結果が得られませんでした。以下の例では横書き用の文字幅は685、縦書き用グリフの高さは1000に設定しています。
高さが1000の場合はデフォルトの高さと同じ値であり、高さが個別に設定されていないとみなされているためか、出力したフォントを確認したところ横書き用の文字幅の値である685が高さとして設定されてしまい、縦書きの文字送りが正常に行われませんでした。
高さを1000でない値に設定すれば解決することですが、1000にしたいケースもあるはずです。これについて筆者はGlyphsの画面上で解決する方法が分かりませんでした。筆者が解決できなかっただけで設定方法があるのかもしれません。設定できれば問題は起こらないはずです。
なお、これは縦書き用グリフをvrt2に含んだ場合の症状であり、vrt2を使用せずvertだけならこのようなことはありません。
４）自動生成されるフィーチャーは特定の条件のみ
Glyphs ハンドブック 2.3にも記載があるとおり自動生成されるフィーチャーは一般的なフィーチャーと特定のルールに従ってグリフ名が付けられたものだけです。
例えばtradフィーチャーには「亜（uni4E9C）」を「亞（uni4E9E）」に置き換えるための情報を入れるべきですが、自動生成でフィーチャーを作成するとこの情報がtradに入りませんでした。
uni4E9Eのように文字コードだけのグリフは自動生成の対象外ということなのかもしれません。
これらのグリフを含むフィーチャーについては手動で編集するなどの対処が必要なようです。
５）一部のグリフは追加直後またはグリフ情報の更新時に名前が変わってしまう
高さを1000でない値に設定すれば解決することですが、1000にしたいケースもあるはずです。これについて筆者はGlyphsの画面上で解決する方法が分かりませんでした。筆者が解決できなかっただけで設定方法があるのかもしれません。設定できれば問題は起こらないはずです。
なお、これは縦書き用グリフをvrt2に含んだ場合の症状であり、vrt2を使用せずvertだけならこのようなことはありません。
４）自動生成されるフィーチャーは特定の条件のみ
Glyphs ハンドブック 2.3にも記載があるとおり自動生成されるフィーチャーは一般的なフィーチャーと特定のルールに従ってグリフ名が付けられたものだけです。
例えばtradフィーチャーには「亜（uni4E9C）」を「亞（uni4E9E）」に置き換えるための情報を入れるべきですが、自動生成でフィーチャーを作成するとこの情報がtradに入りませんでした。
uni4E9Eのように文字コードだけのグリフは自動生成の対象外ということなのかもしれません。
これらのグリフを含むフィーチャーについては手動で編集するなどの対処が必要なようです。
例えば名前が「zero.zero.full」のグリフを追加するとその直後に「zero.full.zero.full」に変わってしまいます。また、既存のAdobe-Japan1-xフォントを開いた後で対象グリフに対してグリフ情報の更新を行った場合も名前が変わります。
Adobe-Japan1-6に含まれるグリフのうち名前が変わってしまうグリフは以下の通りです。
CID
|
変更前のグリフ名
|
変更後のグリフ名
|
8228
|
zero.zero.full
|
zero.full.zero.full
|
12070
|
cornerbracketleft.short.half
|
cornerbracketleft.half.short.half
|
12071
|
cornerbracketright.short.half
|
cornerbracketright.half.short.half
|
12133
|
cornerbracketleft.short.vert
|
cornerbracketleft.vert.short.vert
|
12134
|
cornerbracketright.short.vert
|
cornerbracketright.vert.short.vert
|
12135
|
whitecornerbracketleft.short.vert
|
whitecornerbracketleft.vert.short.vert
|
12136
|
whitecornerbracketright.short.vert
|
whitecornerbracketright.vert.short.vert
|
12657
|
parenleft.full.ruby.vert
|
parenleft.full.vert.ruby.vert
|
12658
|
parenright.full.ruby.vert
|
parenright.full.vert.ruby.vert
|
12659
|
tortoiseshellbracketleft.ruby.vert
|
tortoiseshellbracketleft.vert.ruby.vert
|
12660
|
tortoiseshellbracketright.ruby.vert
|
tortoiseshellbracketright.vert.ruby.vert
|
16268
|
bartop.dentistry
|
bartop-dentistry
|
16269
|
barbottom.dentistry
|
barbottom-dentistry
|
16332
|
endash.full.vert
|
endash.vert.full.vert
|
20921
|
apostrophe_S
|
quoteright_S
|
変更後のグリフ名でAdobe-Japan1-xフォントを出力するとグリフが適切なCID番号に割り当てられません。Adobe-Japan1-6の場合はCID番号0〜23057が決められた範囲ですが、グリフ名が変わった後でフォントを出力するとそのグリフは範囲外のCID番号に割り当てられてしまいます。このことからAdobe-Japan1-xフォントの場合は変更前のグリフ名を使わなければならないようです。
これらのグリフは一度名前が変わってしまうとGlyphsの画面上で名前を戻そうとしても戻すことができませんでした。
今回作成したフォントではAFDKOを使用してAdobe-Japan1-6の雛形フォントを作成し、それをGlyphsに読み込むことでグリフ名の一覧を取得しています。雛形フォントを読み込むと変更前のグリフ名で読み込まれ、グリフ情報の更新を行わなければグリフ名が保たれるのでそれをベースに作成することでこの問題に対処しました。
例えばグリフ名「acutecomb」はコンビネーション用のグリフであり通常この文字の幅は0emです。このグリフは新規に追加すると文字幅が600emですがフォントの出力時に0emとなります。また、ユーザーが画面上で0emでない値に設定しても同様にフォントの出力時に0emとなりました。
つまり特定のグリフはユーザーがGlyphsの画面上で設定した文字幅と違う値で出力されてしまうということです。
この動作はGlyphData.xmlの内容に従って行われています。GlyphData.xmlについてはGlyphs ハンドブック 2.3を参照してください。GlyphData.xmlの中でサブカテゴリ（subCategory）がNonspacingと定義されているグリフは同様の結果となります。
気になる点としては縦書き用に90度回転したグリフである「acutecomb.vert」や「acutecomb.rotat」の場合も同様にフォントを出力するとグリフの横幅（hmtxのadvanceWidth）が0emになる点です。これについてはサブカテゴリをOtherなどに変えて横幅を1000emに変更したほうが良いかもしれません。
今回作成したフォントは全てのグリフに対しても幅を設定したい特殊なケースなので、対象グリフを選択したうえで「編集」メニューから「選択内容のプロパティを編集」を実行し、サブカテゴリをOtherに変更しています。
ROSがAdobe-Japan1-xに設定されており、フィーチャー画面に字体切り替え情報を全く追加していない状態ではフォントの出力でエラーが発生することがあります。
エラーメッセージの内容はグリフの追加状況によって変わりますがグリフが存在しない（CID not found in font）ことを知らせるものです。
例えば新規にフォントを作成してROSをAdobe-Japan1-xに設定、何文字かグリフが存在している状態でフォントを出力するとこのエラーを目にすることになります。
フィーチャー画面に字体切り替えの情報が全く存在しないとGlyphs内部にあるフィーチャー定義が使われるようです。Glyphs内部にあるフィーチャー定義は必要なグリフが揃っていることを前提としたフルセットの定義であるため、このフィーチャー定義の中で使われているグリフが不足しているとエラーが発生してしまいます。
旧バージョンのGlyphs 2.3ではエラーが発生せず出力されたフォントには中身が空のGSUB情報が付加されていました。
フィーチャー画面に1つ以上の字体切り替え情報を追加するか、必要なグリフを追加すればエラーを回避できます。
８）Glyphsが内部に保持するフィーチャー定義の一部は適切ではない
前述のとおり特定の条件ではGlyphsの内部にあるフルセットのフィーチャー定義が使われますが、このフィーチャーは一部の情報が適切ではないようです。
例えばフィーチャー画面に字体切り替え情報を追加せずにAdobe-Japan1-6フォントを出力するとGlyphsは内部にある以下のファイルを使用してフォントを出力しています。
使用するcmapファイル：
/Applications/Glyphs.app/Contents/PlugIns/OTF.glyphsFileFormat/Contents/Resources/cmapAdobe-Japan1.txt
使用するAdobe-Japan1-6用のフィーチャー定義ファイル：
/Applications/Glyphs.app/Contents/PlugIns/OTF.glyphsFileFormat/Contents/Resources/gsubAdobe-Japan1-6.txt
このとき使用しているcmapファイルはJIS2004フォントを出力するためのcmapですが、Adobe-Japan1-6用のフィーチャー定義ファイルの中にはJIS2004フォントには必要ないjp04フィーチャーが含まれており、逆に必要なjp90フィーチャーが含まれていません。また、jp78,jp83,exptフィーチャーに含めるべきグリフの情報も不足しているようです。
Glyphsの内部にはROS別に「gsubAdobe-Japan1-3.txt」「gsubAdobe-Japan1-3+.txt」「gsubAdobe-Japan1-4.txt」「gsubAdobe-Japan1-5.txt」も存在しますが、これらの内容について筆者は未確認です。
９）フォントの名前情報が期待どおりに設定できないケースがある
出力したフォントの内部に含まれるフォント名情報（nameテーブル内の情報）はGlyphsのフォント情報画面で設定した内容から自動的に設定されるものがあります。フォント情報画面で名前に関する色々な設定を試してみましたが、出力したフォントにどうしても期待どおりの名前が設定できないケースがありました。
このケースはおそらく日本語フォントを出力するときだけ発生する問題です。
英語のファミリ名が「SampleFont Pr6N」でスタイル名が「R」のとき、フルネームを「SampleFont Pr6N R」にしたいのに「SampleFont Pr6NR」のようにスタイルの前にスペースが入らない。スタイルリンクでボールド指定しているフォントの日本語フルネームを「サンプルフォント Pr6N B」に設定したいところが「サンプルフォント Pr6N B Bold」と設定されてしまうなどです。
フォントにどのような名前が設定されたかを確認するには出力したフォントをその都度AFDKOなど他のアプリケーションを使って確認しなければならず余計な手間がかかります。
これについてはGlyphsだけで期待どおりの結果を得る方法がわかりませんでした。Glyphsの設定だけで対処できないようなら、例えばAFDKOなどを使って出力したフォントのnameテーブルを修正するなどの方法で対処するしかないかもしれません。
この問題は.notdefグリフの文字幅が全角幅（1000em）の日本語OTFを作成した場合に発生します。この問題はWord for Mac 2011の仕様に加え、出力されたフォントに含まれるcmapの内容が関係しています。
Glyphsが出力した日本語OTFに含まれるMac Japanese用のcmapは文字コード0x00に.notdefグリフを割り当てるだけの内容になっており、このcmapを使って文字コードから適切なグリフにアクセスすることはできません。Word for Mac 2011ではこの内容が原因で全角文字の送り幅が広くなるという問題が発生しているようです。
Glyphsのデフォルト.notdefは文字幅が600emなのでこの問題は発生せず、独自に.notdefを追加した場合も1000emでなければ問題は発生しません。
.notdefの文字幅は1000emで良いはずなので、Mac Japanese用のcmapに適切な値をセットするなどの対処を行ったほうが良いと考えます。
これについてはGlyphsだけでcmapの問題を解決する方法がわかりませんでした。Glyphsの設定だけで対処できないようなら、GlyphsがTempフォルダに出力した作業ファイルを修正してコマンドラインからビルドするか、AFDKOなどを使って出力したフォントのcmapテーブルを修正するなどの方法で対処するしかないかもしれません。
今回作成したフォントにはUnicode Variation Sequences (UVS)用のcmapが含まれません。そのためUnicodeによる字体の切り替えはできません。
Glyphs側の設定でUnicode Variation Sequences (UVS)用のcmapを付加する方法が分かりませんでした。
Glyphsの設定だけで対処できないようなら、GlyphsがTempフォルダに出力した作業ファイルを修正してコマンドラインからビルドするか、AFDKOなどを使って出力したフォントのcmapテーブルを修正するなどの方法で対処するしかないかもしれません。
１２）ROSがAdobe-Japan1-3+で出力したフォントのROSがAdobe-Japan1-3になる
ROSを「Adobe-Japan1-3+」に設定したときは、JIS2004対応のStdNフォントを出力することを意味しているのだと思いますが、この設定でフォントを出力するとフォント内部のROSが「Adobe-Japan1-3」になりました。
Adobe Systems社がFont technical notesサイトで公開している「Building JIS2004-Savvy OpenType Fonts」に含まれるドキュメントを見るとJIS2004対応のStdNフォントはROSを「Adobe-Japan1-6」に設定するように説明しているのでStdNを作成する目的なら「Adobe-Japan1-6」を選択するほうが良いと思います。
しかし、Glyphsは設定したROSに応じて内部に保持している5種のフィーチャー定義ファイルの中からどれを使用するか決めているようなので、StdNフォントを作成する目的で「Adobe-Japan1-3+」の代わりに「Adobe-Japan1-6」を指定したとき、他の動作や出力結果に悪影響がないか確認したほうが良いかもしれません。
今回はAdobe-Japan1-6フォントを作成するのが目的なので詳しく検証は行いませんでした。
１３）FontBookのスマートコレクションの「日本語」に名前が表示されないことがある
例えばロゴフォントを作成する目的で特定の文字だけを含む日本語フォントを作る場合など極端に文字数が少ないときに発生することですが、OS XのFontBookのスマートコレクションにある「日本語」分類に作成したフォントの名前が現れない場合があります。
※この確認はFontBook バージョン 5.0.2 (262.1)で行っており他のバージョンでは未確認です。
フォントの中にはフォントがサポートするコードページ情報（codePageRanges）がありますが、日本語フォントの場合はこの情報にある「JIS/Japan」という項目が有効になっているのが一般的です。
しかし、筆者の確認では「ひらがな」または「カタカナ」に33文字以上のグリフがないと「JIS/Japan」が有効になりませんでした。第一、第二水準漢字が全て揃っていても「ひらがな」または「カタカナ」が存在しないと「JIS/Japan」が有効になりませんでした。
「JIS/Japan」が無効になっているフォントはスマートコレクションの「日本語」分類に名前が現れないようです。FontBookのスマートコレクション情報を使用するアプリケーションや、同様の認識を行っているアプリケーションでも同じ結果になる可能性があります。
Glyphs ハンドブック 2.3の説明にあるようにcodePageRangesの情報は「しっかりと機能している前提」なので、グリフが不足している場合に「JIS/Japan」が無効になることはフォントの仕様としては正しいのかもしれません。しかし、ユーザーの使い勝手を考えて有効にしたい場合があるかもしれません。
解決するためには「ひらがな」または「カタカナ」に全てのグリフを追加しておくか、もしくはGlyphsのカスタムパラメータに「codePageRanges」を追加してユーザーが適切な値を設定しなければならないようです。（追加するグリフは空白やゲタ文字でも構いません）
33文字以上という条件が何を意味するのか分かりませんでした。他の要因でも「JIS/Japan」の内容が変わることがあるかもしれません。
１４）ステムとアラインメントゾーン
Glyphsにはフォント情報画面にヒンティングのための垂直ステム、水平ステム、アラインメントゾーンを設定する項目があります。
Adobe Systems社の日本語OTFや市販の日本語OTFではローマングリフや漢字など字種ごとにステムとアラインメントゾーンが設定されています。
Glyphsのフォント情報画面には字種ごとに値を設定する項目が無いようなので設定した値は漢字や仮名を含む全てのグリフに対して適用されてしまうはずです。
Glyphsのフォント情報画面でアラインメントゾーンにローマングリフ用の値を設定したとき、その値が漢字や仮名の表示結果にどのような影響を与えるか、それは無視できる程度のものか、無視できないほど影響するならGlyphs上でどのように対処するのか、これについて筆者は十分な確認ができないので気になる点として記載しておきます。
Adobe Systems社のアプリケーションなど、ヒンティングが有効な環境（アプリケーションやOS）を使用して、解像度が低いディスプレイに対して小さな文字で表示すれば何らかの違いが出るはずです。
１５）Tempフォルダの中身について
Glyphsでフォントを出力すると「/Users/ユーザー名/Library/Application Support/Glyphs/Temp」の中に作業用のファイルやフォルダが作られます。これらはフォントごとに作られます。
出力時にエラーが発生した場合はTempフォルダにあるファイルが問題の解決に役立つ場合があるので状況によっては意味のあるものです。
フォントの名前を変えてフォントをいくつも試作しているとTempフォルダの中にファイルが増えていきます。例えば今回試作したフォントの場合は1書体分の作業ファイルが合計で100MBを超えます。今回の作業で名前を変えて多くのパターンを試しているとTempフォルダ全体のサイズが1GBを超えていることもありました。
ストレージの空きが十分ある場合は気にすることはないと思いますが、そうでないなら定期的にTempフォルダにある不要になったファイルを削除したほうが良いかもしれません。
４．作成したGlyphsファイル
今回作成したAdobe-Japan1-6フォントのGlyphsファイルの仕様は以下のとおりです。
雛形フォント
このファイルを作成するにあったって、あらかじめAFDKOを使って作成した雛形フォントをGlyphsに読み込んで作成しています。
Adobe Systems社がFont technical notesサイトで公開している「Building JIS2004-Savvy OpenType Fonts」に含まれるAdobe-Japan1-6用のフィーチャー定義ファイル（aj16-gsub-jp04.txt）とAFDKOを使用して、Adobe-Japan1-6の全23058文字が空白文字のフォントを作成して雛形フォントとしました。
Adobe Systems社のFont technical notesサイト：
http://www.adobe.com/jp/devnet/font.html
フォント名
フォントの名前は以下のとおりです。
英語名：CidNumGlyph Pr6N R
日本語名：CID番号グリフ Pr6N R
ポストスクリプト名：CidNumGlyphPr6N-Regular
グリフ
Adobe-Japan1-6には23058文字のグリフが含まれておりCID番号ごとに作成するグリフが決まっています。一部の文字はプロポーショナル幅、半角幅など文字の幅も決められています。
今回作成したダミーグリフはこれらのルールに従っていません。
各グリフにはグリフが属するROSを表す「AJ1-0」〜「AJ1-6」とCID番号を表す5桁の数字を入れています。幅と高さが全角と決められているグリフは1000em x 1000em、その他の文字幅は800em、半角幅、1/3幅、1/4幅と決められているグリフについても800emです。時計回りに90度回転したグリフやプロポーショナル仮名は高さが800emで作成しています。
このファイルに含まれるグリフは雛形フォントをGlyphsに読み込んだ後でGlyphsのマクロを使って各グリフの内容を自動生成したものです。Glyphsファイルの中に含まれる名前がアンダーバーから始まるグリフは各グリフが使用しているコンポーネントです。アンダーバーから始まるグリフは出力されたフォントには含まれません。
例えば「Aあ亜辻」をこのフォントで表示すると以下の右側のようになります。縦書き表示や字体切り替えを行うとその状況に応じてグリフが変わるので表示される番号が変わります。
グリフ名
Adobe-Japan1-6フォントを作成するためにはAdobe-Japan1-6に含まれるグリフの名前を全て知らなければなりません。Glyphsに標準で用意されている文字体系では全ての名前を知ることができません。このファイルでは雛形フォントをGlyphsに読み込むことで全てのグリフ名を取得しています。
GSUB
Adobe-Japan1-6フォントに含まれるフィーチャーの定義を全て自分で作成することはかなり手間のかかる作業です。また、Glyphsによって自動生成されたフィーチャー定義だけでは不足する定義があるため自動生成の結果をそのまま使うことができません。このファイルではあらかじめAFDKOを使って作成した雛形フォントをGlyphsに読み込むことでAdobe-Japan1-6用のフィーチャーを取得しています。
GPOS
このファイルにはカーニングなどGPOSに関するフィーチャーは含みません。
cmap
このファイルによって出力されるフォントのcmapは前述のとおりMac Japanese用のcmapが適切ではありません。そのためWord for Mac 2011で全角文字の文字送りが広くなります。また、Unicode Variation Sequences (UVS)用のcmapが含まれません。そのためUnicodeによる字体の切り替えはできません。
panose
panoseはフォントのデザインに応じて設定するものですが今回のフォントにデザインは関係ないので全てAny（値が0）に設定しています。
LanguagesystemsとBASE
以下の内容を参考にしてフィーチャー画面のプレフィックスにLanguagesystemsとBASEを追加しています。
Adobe Systems社のブログ「OpenTypeフォント作成のすべて」：
http://blogs.adobe.com/CCJKType/files/2012/06/afdko-mhattori-20120625.pdf
glyphOrder
Adobe-Japan1-xフォントはglyphOrderを設定する必要はありませんが、このファイルではカスタムパラメータにglyphOrderを設定しています。glyphOrderにはAdobe-Japan1-6に含まれる全てのグリフ名をCID順に列挙しています。これにより一覧画面でグリフがCID順に表示されます。
このファイルに含まれるグリフに対してグリフ情報の更新を行わないでください。前述のとおりグリフ情報を更新すると一部のグリフの名前が変わってしまうため出力時にエラーが発生して出力できなくなります。
注意２
このファイルによって出力されるフォントはグリフにCID番号を入れた特殊なフォントであることに注意してください。確認のために作成した特殊なフォントであり通常の文字を表示することはできません。文字の代わりにCID番号が表示されます。アプリケーションのフォントメニューが実際のグリフで表示される（WYSIWYGメニュー）ではフォントの名前もCID番号を表すグリフで表示されます。また、一部のグリフは一般的なフォントの文字幅と異なります。例えば半角仮名を表示したときは文字幅が500emではなく800emのグリフが現れます。
注意３
このファイルには23058文字＋コンポーネントグリフが含まれているため特定の処理でかなり時間がかかる場合があります。例えばMacBook Air（1.3 GHz Intel Core i5 メモリ4GB）ではオートヒント無しの設定でフォントを出力すると完了までに5分程度かかりました。オートヒント有りで出力すると20分程度かかりました。ヒントを有効にするまでもないので無効のまま出力したほうが良いでしょう。
Glyphsファイルのダウンロード
今回作成したフォントはダミーのグリフなので実用的なフォントではありませんが、作成したGlyphsファイルをサンプルとして公開します。このファイルは自由に修正を行って構いませんが内容と結果については一切保証しません。自身の判断と責任のうえで使用してください。
以下のURLにアクセスして「CidNumGlyphPr6N.zip」をダウンロードしてください。
https://drive.google.com/file/d/0B-B3lykkVTBHeHVRS3l0QzR0dkk/view?usp=sharing
URLを選択するとダウンロードページが現れます。ダウンロードページの右上にあるダウンロードアイコンを選択するとダウンロードが始まります。
以上です。
更新履歴：
2017年5月25日：「４．作成したGlyphsファイル」＝＞「グリフ」文中の「ABCあいう漢字」を「Aあ亜辻」に変更
2017年4月28日：公開
0 件のコメント:
コメントを投稿