Glyphs 2.4.4 (1075)からGlyphs 2.5.xにアップデートした際の個人的に気になったところをメモ。
※記載している内容は2018年6月12日現在において正式版であるGlyphs 2.5.1 (1141)を使用して確認したものです。他のバージョンでは結果が異なるかもしれません。将来のバージョンで結果が異なる場合はバージョン表記とともに追記する場合があります。
※1つ前の正式バージョンであるGlyphs 2.5 (1131)は筆者の環境においてフォント情報ウインドウを開いた後で新しいフォントウインドウを開くなどするとアプリが異常終了するため確認対象から除外しています。Glyphs 2.5.1 (1141)でこの問題は発生しません。
※テスト環境：MacBook Pro Mid 2015 Core i7 2.8GHz 16GBメモリ macOS Sierra 10.12.6、外部ディスプレイ使用
※個人の限られた環境で確認しているため他の環境では結果が異なる可能性もあります。また、筆者の知識不足などにより内容に誤りがあるかもしれません。この点を了承のうえお読みください。
１）glyphsファイルを開くとバージョン確認メッセージが現れる
異なるバージョンで保存されたglyphsファイルを開くと確認メッセージが現れます。開いたglyphsファイルを上書き保存すると、そのファイルに対するメッセージは現れなくなります。
また、上書き保存する・しないに関係なく画面上の「Do not show this warning ever again」をチェックしてこのメッセージを閉じると、以後このメッセージは現れなくなります。
「Do not show this warning ever again」をチェックして非表示にした後でもう一度このメッセージが現れるようにしたい場合は「ターミナル」アプリケーションから以下のコマンドを実行すると現れます。Glyphs 2.5.1 (1141)で確認済み。将来のバージョンでこの方法が使用できるかどうかわかりません。自己責任で行ってください。
defaults write com.GeorgSeifert.Glyphs2 GSDontShowVersionAlert -bool false
現在の状態を確認したいときは「ターミナル」アプリケーションを使って以下のコマンドを実行すると確認できます。
実行した後で出力された結果が0ならメッセージを表示する状態、1なら表示しない状態です。
２）glyphsファイルを開くとグリフの状態に関するメッセージが現れることがある
開いたglyphsファイルの問題点をユーザーに知らせ、解決方法を選択してもらうために表示しているようです。チェックリストの内容は開いたファイルの状況に応じて変わります。
上記のメッセージは自動整列が有効な状態でコンポーネントを使って作成したグリフに対するものであり、2つとも文字幅が適切でないために警告が出ています。Glyphs 2.4.xではこのような状況が発生する可能性がありました。チェックリストの項目をチェックせずに［Keep Selected］を押すと文字幅が適切な値に変更されます。
現在の状態を維持したいならチェックリストの項目をチェックして［Keep Selected］を押します。そうすることでチェックしたグリフに含まれるコンポーネントは自動整列が無効になり、状態が維持されます。
［Check］をONにすると全ての項目がチェック状態になります。［Show in Tab］をONにすると［Keep Selected］を押した後に全ての対象グリフを1つの新しいタブにまとめて表示します。
上記のメッセージは文字幅に関するメッセージですが、メッセージの内容は状況によって変わります。内容に応じて現状を維持するか、それとも修正を適用するか決めることになります。
３）1つのグリフに対して2つのUnicodeを適用できるようになった
これは源ノ角ゴシックのように派生フォントの作成が許可されているフォントを読み込んでカスタマイズするようなケースで役立ちます。
例えば、源ノ角ゴシックのグリフ「風」は康熙部首の2FB5とCJK統合漢字の98A8の2つのUnicodeが割り当ててられています。Glyphs 2.4.xで源ノ角ゴシックを開くと2FB5しか認識せず、通常の日本語表示に使われる98A8が欠落してしまい、そのままOTFを出力すると98A8の「風」が表示できませんでした。
Glyphs 2.5.1 (1141)では1つのグリフに2つのUnicodeを割り当てられるようになったので、上記のようなケースにも対応できるようです。
※ただし、2つのUnicodeが割り当てられているグリフに対してGlyphs上で「グリフ情報を更新」するとGlyphs上で割り当てられていた2つのうち1つのUnicodeが消えてしまいました。どちらが消えるかはグリフの名前によって変わるようです。グリフの名前が「uni2FB5」なら98A8が消え「uni98A8」なら2FB5が消えます。将来変更になるかもしれませんが、Glyphs 2.5.1 (1141)でこの方法を使う場合は「グリフ情報を更新」しないか、このことに注意して行ったほう良さそうです。
※ただし、2つのUnicodeが割り当てられているグリフに対してGlyphs上で「グリフ情報を更新」するとGlyphs上で割り当てられていた2つのうち1つのUnicodeが消えてしまいました。どちらが消えるかはグリフの名前によって変わるようです。グリフの名前が「uni2FB5」なら98A8が消え「uni98A8」なら2FB5が消えます。将来変更になるかもしれませんが、Glyphs 2.5.1 (1141)でこの方法を使う場合は「グリフ情報を更新」しないか、このことに注意して行ったほう良さそうです。
４）プロポーショナルメトリクス（palt）と縦組みプロポーショナルメトリクス（vpal）
グリフの編集画面でプロポーショナルメトリクス（palt）と縦組みプロポーショナルメトリクス（vpal）を追加できます。
この機能はGlyphs 2.4.2で追加された機能ですが、古いバージョンではアンカーをマウスドラッグすると不自然な挙動になりました。Glyphs 2.5.1 (1141)は改善しているようです。
プロポーショナルメトリクス（palt）を追加する場合は「LSB」と「RSB」2つのアンカーを追加します。LSBからRSBまでの間隔がプロポーショナルメトリクスを適用したときの文字幅になります。
縦組みプロポーショナルメトリクス（vpal）を追加する場合は「TSB」と「BSB」2つのアンカーを追加します。TSBからBSBまでの間隔が縦組みプロポーショナルメトリクスを適用したときの文字高になります。
以下は「あ」「い」「う」の3文字にpaltとvpalを適用したOTFを使ってWebブラウザ（Google Chrome バージョン 66.0.3359.181）で表示した結果です。CSSで"font-feature-settings"に"palt”または”vpal"を指定しています。
筆者の環境では、Glyphs 2.5.1 (1141)でグリフ編集画面に複数の文字を表示している状態で2文字目以降のLSBアンカーをマウスドラッグすると不自然な挙動になりました。1文字だけのときは問題ありません。アンカーはキーボードのカーソルキー（Shiftキーやcommandキーの組み合わせも有り）で移動できるほか、Z,Y座標の数値を直接入力して変更できるので、同様の問題が起こるならキーボードで移動するのが良いと思います。
paltやvpalを確認するにはOpenType機能に対応しているアプリが必要です。このプログではHTMLを記述してGoogle Chromeを使って表示した結果を掲載していますが、Adobe InDesign などOpenType機能に対応しているアプリを使用しているならそれらで確認できます。
なお、OpenType機能に対応しているアプリでも縦組みプロポーショナルメトリクス（vpal）を適切に処理できないものがあります。例えばmacOS 10.12.xに付属するテキストエディットは正しく表示できませんでした。同様の問題はOSに付属のフォントやAdobe社製のフォントでも発生するためアプリまたはOS側の不具合の可能性があります。
プロポーショナルメトリクスはGlyphs上のカーニングプレビュー画面で確認できます。同じグリフにカーニングとプロポーショナルメトリクスの両方が設定されている場合は同時に適用された状態でプレビューされるようです。
５）字幅半角メトリクス（halt）と縦組み字幅半角メトリクス（vhal）
グリフの編集画面で字幅半角メトリクス（halt）と縦組み字幅半角メトリクス（vhal）を追加できます。
字幅半角メトリクス（halt）を追加する場合は「HALT」という名前のアンカーを追加します。HALTの水平線が字幅半角メトリクスを適用したときの文字幅になります。
縦組み字幅半角メトリクス（vhal）を追加する場合は「VHAL」という名前のアンカーを追加します。VHALの垂直線が縦組み字幅半角メトリクスを適用したときの文字高になります。
以下はhaltとvhalを適用したOTFを使ってWebブラウザ（Google Chrome バージョン 66.0.3359.181）で表示した結果です。CSSで"font-feature-settings"に"halt”または” vhal"を指定しています。
以下のように筆者の確認では字幅半角メトリクス（halt）について期待通りの結果が得られませんでした。Glyphsが出力しているメトリクス値に誤りがあるようです。
＜2019年2月8日追記：正式リリース版のGlyphs 2.6 (1192)は不具合が修正されているため以下に記載している対処は必要ありません。＞
筆者の確認では字幅半角メトリクス（halt）が期待通りの結果になりませんでした。この対処の方法としてHALTアンカーを使用せずフォント情報（command+I）ウインドウのフィーチャータブに手動で”halt”を追加する方法があります。
フィーチャータブに手動で”halt"を追加したときの結果は以下のとおり。
６）OTF出力でMacJapaneseのcmapを付加しなくなった
＜2019年6月1日追記：正式リリース版のGlyphs 2.6 (1192)、2.6.1 (1230)では、Glyphs 2.4.xと同じ仕様にも戻ってしまったようです。そのため「.notdef」グリフの文字幅を全角幅にするとMicrosoft Word for mac 2011で全角文字の文字送りが不適切に広くなります。＞
Glyphs 2.4.xで出力した日本語OTFにはMacJapaneseのcmap（ShiftJISの文字マップ情報）が含まれていましたが、そのcmapの内容が適切でなかったため「.notdef」グリフの文字幅を全角幅にして出力した日本語OTFをMicrosoft Word for mac 2011で使用すると全角文字の文字送りが不適切に広くなる問題がありました。
Glyphs 2.5.1 (1141)では出力した日本語OTFにはMacJapaneseのcmapが含まれないため上記の問題は発生しません。
７）OTF出力時のサブルーチン化がデフォルトで無効になっている
＜2019年2月8日追記：正式リリース版のGlyphs 2.6 (1192)はサブルーチン化がデフォルトで有効になっています。バージョンによって変わる可能性があるとしたらユーザー自身が制御できるように「Disable Subroutines」パラメータを追加してON/OFFしたほうが良いかもしれません。＞７）OTF出力時のサブルーチン化がデフォルトで無効になっている
Glyphs 2.5.1 (1141)ではOTFを出力する際のサブルーチン化がデフォルトで無効になっています。Glyphs 2.4.xではデフォルトで有効になっていました。
サブルーチン化を行うとOTFのファイルサイズをより小さくできる場合があります。有効、無効でファイルサイズがどの程度変わるかはグリフのデザイン次第です。フォントの中に同じ形のパスが多ければ小さくなりますが、画像を単純にスキャンしたような不規則に制御点が存在するデザインならあまり小さくならないでしょう。
Glyphs 2.5.1 (1141)ではサブルーチン化がデフォルトで無効になっているので、サブルーチン化の処理が省かれている分、OTFを出力する時間が短くなっています。
カスタムパラメータに「Disable Subroutines」を追加して、その値であるチェックマークをOFFにするとサブルーチン化を有効にできることを確認しています。
以前このブログに掲載した「CID番号グリフ Pr6N R」というサンプルフォントを使って出力時間と出力サイズを比較してみました。
テスト環境：
MacBook Pro Mid 2015 Core i7 2.8GHz 16GBメモリ macOS Sierra 10.12.6、外部ディスプレイ使用
テスト結果：
【ケース１：サブルーチン化がON】
使用バージョン：Glyphs 2.4.4 (1075)
サブルーチン化：デフォルトでサブルーチン化がON
出力オプション：重なったパスを合体ON、オートヒントOFF
出力にかかった時間：約4分23秒
出力ファイルサイズ：2,792,944 バイト（ディスク上のサイズ2.8 MB）
【ケース２：サブルーチン化がOFF】
使用バージョン：Glyphs 2.5.1 (1141)
サブルーチン化：デフォルトでサブルーチン化がOFF
出力オプション：重なったパスを合体ON、オートヒントOFF
出力にかかった時間：約3分19秒
出力ファイルサイズ：15,713,976 バイト（ディスク上のサイズ15.7 MB）
【ケース３：サブルーチン化がON】
使用バージョン：Glyphs 2.5.1 (1141)
サブルーチン化：カスタムパラメータでサブルーチン化をON
（Disable Subroutinesを追加して値をOFF）
出力オプション：重なったパスを合体ON、オートヒントOFF
出力にかかった時間：約4分33秒
出力ファイルサイズ：2,787,184 バイト（ディスク上のサイズ2.8 MB）
使用したサンプルフォント「CID番号グリフ Pr6N R」は全ての文字がコンポーネントの組み合わせで構成されているためサブルーチン化の効果が大きく現れます。一般的なフォントではファイルサイズの差がここまで大きくなることはないと思います。
ケース１とケース３はどちらもサブルーチン化がONですがファイルサイズが異なります。これはGlyphs 2.5.1 (1141)がMacJapaneseのcmap（ShiftJISの文字マップ情報）を付加していないことによるものです。
Glyphs 2.4.xで作成したglyphsファイルがあり、内容を変更していないのにGlyphs 2.5.1 (1141)を使ってOTFを出力したらファイルサイズが大きくなってしまったことを気するなら、カスタムパラメータに「Disable Subroutines」を追加して値のチェックをOFFにすれば以前と近いファイルサイズになるはずです。
８）glyphsファイルに対して独自のカスタムフィルタファイルを持てるようになった
独自のカスタムフィルタファイルをglyphsファイルと同じ場所に置くことで、そのglyphsファイルを開いたときだけ利用できるカスタムフィルタを自作できるようになりました。
独自のカスタムフィルタファイルは「/Users/<ユーザー名>/Library/Application Support/Glyphs」にある「CustomFilter.plist」と同じ形式で作成します。
例：
・「CustomFilter.plist」をコピーしてファイル名を独自の名前、例えば「CustomFilter マイフィルタ.plist」に変更します。（”CustomFilter”の後ろに半角スペース文字を入れ、その後ろに独自の名前を追加する。拡張子は”plist"）
・「CustomFilter マイフィルタ.plist」をテキストエディタで開いて内容の一部を変更します。以下は「あいう」という名前でリストフィルタを作成してその中に「a-hira」「i-hira」「u-hira」の3文字を列挙、さらに「アイウ」という名前でリストフィルタを作成してその中に「a-kata」「i-kata」「u-kata」の3文字を列挙した場合の例です。
＝＝＝＝＝＝＝＝
CustomFilter マイフィルタ.plistの例
＝＝＝＝＝＝＝＝
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>name</key>
<string>あいう</string>
<key>list</key>
<array>
<string>a-hira</string>
<string>i-hira</string>
<string>u-hira</string>
</array>
</dict>
<dict>
<key>name</key>
<string>アイウ</string>
<key>list</key>
<array>
<string>a-kata</string>
<string>i-kata</string>
<string>u-kata</string>
</array>
</dict>
</array>
</plist>
＝＝＝＝＝＝＝＝
・修正した「CustomFilter マイフィルタ.plist」をglyphsファイルと同じ場所に置きます。
・glyphsファイルを開いて「マイフィルタ」が追加されていることを確認してください。
９）UFOファイルにグリフの高さ情報が反映されるようになった
Glyphs 2.4.xではUFOファイルに出力したときグリフの高さ情報が保存されませんでした。また、グリフの高さ情報を含むUFOファイルを読み込んでも画面に反映されませんでした。Glyphs 2.5.1 (1141)ではUFOファイルでもグリフの高さ情報を扱えるように変わっています。
10）大文字グリフに対して2つのUnicodeが付加される場合がある
＜2018年8月4日追記＞
これはGlyphs 2.5で追加された機能です。例えば、大文字A〜Zだけのフォントを作成する目的でメインウインドウのフォントビューから小文字を削除したとします。小文字が存在しない状態でA〜Zに対して「グリフ情報を更新」を実行するとA〜Zに2つめのUnicodeが追加されます。追加された2つめのUnicodeは小文字のUnicodeです。同様の処理はアクセント付き文字に対しても行われます。
この状態で出力したフォントはキーボードからA〜Zを入力すれば通常通り表示できるのに加えて、キーボードからa〜zを入力した場合も大文字のA〜Zが表示されることになります。
大文字に小文字のUnicodeが追加されているときに「グリフを追加」で対象の小文字を追加すると「いくつかのグリフはすでにフォント内に存在しています。」という確認メッセージが現れ、実行すると大文字から小文字のUnicodeが取り除かれます。
対象グリフを選択したうえで「グリフ情報を更新」を実行すると現在の状態に応じて2つめのUnicodeが自動的に追加または削除される他、ユーザーがUnicode部分を選択して個別に追加または削除することもできます。
なお、大文字に小文字のUnicodeが追加されているときに他のGlyphsファイルから小文字のグリフをコピー＆ペーストしたときは大文字から小文字のUnicodeを削除してくれませんでした。そのためフォント内にUnicodeが重複する状態になります。重複している状態でフォントを出力すると以下のようなメッセージが現れてフォントを出力できません。小文字のUnicodeを持つ大文字を既に小文字が存在する別のGlyphsファイルにコピー＆ペーストした場合も同様です。
フォントの出力時にこのメッセージが現れたら対象グリフを選択したうえで「グリフ情報を更新」を行うか、個別にUnicodeを削除して重複を解消してください。
常に大文字と小文字がセットで存在していれば気にする必要はないと思いますが、誤って一部の小文字が抜けてしまっている状態で「グリフ情報を更新」を行うとユーザーに対する確認メッセージ等も無く自動的に大文字に対して小文字のUnicodeが追加されてしまうのでトラブルの原因になることがあるかもしれません。このような処理が行われることを認識しておいたほうが良いでしょう。
11）メトリクスのアンカーを持つコンポーネントを利用するときの注意
＜2019年2月8日追記＞
プロポーショナルメトリクスのアンカー（LSBとRSB , TSBとBSB）、字幅半角メトリクスのアンカー（HALT , VHAL）を持っているコンポーネントを追加すると、それらのアンカー情報が追加先のグリフに適用されてしまうことがあります。
例えば、以下のように横書き用の小さい「あ」である「asmall-hira」に対してpalt（LSBとRSBアンカー）を追加していたとします。
その後「asmall-hira.vert」の中にコンポーネントとして「asmall-hira」を追加して位置を調整し縦書き用の小さい「あ」を作成します。
この状態でOTFを出力すると「asmall-hira.vert」に対してコンポーネント「asmall-hira」にあるpalt（LSBとRSBアンカー）の情報が付加されてしまいます。通常は縦書き専用のグリフに横書き用のpaltを付加することはありません。この状態で出力したOTFの中には使われないpalt情報が含まれることになります。同様のケースは字幅半角メトリクスでも発生します。
以下はOTFを出力したときにGlyphsの「Temp」フォルダに作られるフォント生成のためのパラメータファイル「features.fea」の一部を抜粋したもので、反転部分が不要な情報です。
また、例えばpaltを持たない全角グリフの中にpaltを持つコンポーネントを追加するようなケースがあったとしたら、そのグリフに対してコンポーネント側のpaltが適用されてしまうため、製作者の意図しない文字送りになってしまう可能性があります。
なお、上記の「asmall-hira.vert」では、追加したコンポーネントを分解し画面に現れたLSBとRSBアンカーを削除してから出力すれば解決しますが、この方法ではコンポーネントを利用する利点が失われてしまいます。
コンポーネントとして使用するグリフは名前の頭にアンダーバーを付けて別に作成し、そのグリフにはメトリクスのアンカーを追加せず、「asmall-hira」と「asmall-hira.vert」はどちらもコンポーネントを追加する形で作成し、そこにメトリクスのアンカーを追加すれば解決できますが、これが最良かどうかはそれぞれ製作者が判断してください。
11）メトリクスのアンカーを持つコンポーネントを利用するときの注意
＜2019年2月8日追記＞
プロポーショナルメトリクスのアンカー（LSBとRSB , TSBとBSB）、字幅半角メトリクスのアンカー（HALT , VHAL）を持っているコンポーネントを追加すると、それらのアンカー情報が追加先のグリフに適用されてしまうことがあります。
例えば、以下のように横書き用の小さい「あ」である「asmall-hira」に対してpalt（LSBとRSBアンカー）を追加していたとします。
その後「asmall-hira.vert」の中にコンポーネントとして「asmall-hira」を追加して位置を調整し縦書き用の小さい「あ」を作成します。
この状態でOTFを出力すると「asmall-hira.vert」に対してコンポーネント「asmall-hira」にあるpalt（LSBとRSBアンカー）の情報が付加されてしまいます。通常は縦書き専用のグリフに横書き用のpaltを付加することはありません。この状態で出力したOTFの中には使われないpalt情報が含まれることになります。同様のケースは字幅半角メトリクスでも発生します。
以下はOTFを出力したときにGlyphsの「Temp」フォルダに作られるフォント生成のためのパラメータファイル「features.fea」の一部を抜粋したもので、反転部分が不要な情報です。
また、例えばpaltを持たない全角グリフの中にpaltを持つコンポーネントを追加するようなケースがあったとしたら、そのグリフに対してコンポーネント側のpaltが適用されてしまうため、製作者の意図しない文字送りになってしまう可能性があります。
なお、上記の「asmall-hira.vert」では、追加したコンポーネントを分解し画面に現れたLSBとRSBアンカーを削除してから出力すれば解決しますが、この方法ではコンポーネントを利用する利点が失われてしまいます。
コンポーネントとして使用するグリフは名前の頭にアンダーバーを付けて別に作成し、そのグリフにはメトリクスのアンカーを追加せず、「asmall-hira」と「asmall-hira.vert」はどちらもコンポーネントを追加する形で作成し、そこにメトリクスのアンカーを追加すれば解決できますが、これが最良かどうかはそれぞれ製作者が判断してください。
【更新履歴】
- 2019.06.01：「６）OTF出力でMacJapaneseのcmapを付加しなくなった」の中にGlyphs 2.6 (1192)、2.6.1 (1230)に関する情報を追記。
- 2019.02.08：「５）字幅半角メトリクス（halt）と縦組み字幅半角メトリクス（vhal）」「７）OTF出力時のサブルーチン化がデフォルトで無効になっている」の中にGlyphs 2.6 (1192)に関する情報を追記。「11）メトリクスのアンカーを持つコンポーネントを利用するときの注意」を追記。
- 2018.08.04：「10）大文字グリフに対して2つのUnicodeが付加される場合がある」を追記
- 2018.06.12：公開
0 件のコメント:
コメントを投稿