今年最後の……FontLab 8 解説
さて、来年辺りにもうそろそろ技術的特異点を突破しそうな勢いでAIの爆発的進化が止まらないので、もはやシンギュラリティしてもクリエイティブな仕事はAIに取って代わられにくいから大丈夫などというような暢気なことは言ってられなくなってきて、なんだったら今ならアートやデザインの分野なんてクリスマスセールの割引期間中で、それを過ぎたらすぐにでもAI使った金儲けの稼ぎ頭になるほどの勢いなんだけど、多くの社会学者なんかが読み間違っていたこのヒトのクリエイティブは機械にわからないはずだというような言説……まぁ、あえていえばそういう「誤解」は、おそらく美とか善とか、そういった形而上なものが機械には理解出来るはずがないという偏見に基づいている。まぁ、理解という意味で言えば本質的なところ機械が何かを「理解」して判断しているわけでは無いので、定義されなければ善悪どころか白黒の判別すらつかないのだが、逆に言えばこのあたりが定義可能になるならば何でも出来るというワケで、深層学習によって機械に神を信じさせる……と、いうか、まぁAIで、到頭神や宗教のような形而上的な概念さえ作り出せる関数が開発されたみたいな罰当たりな話を聞いたので、マジか〜kwskって、ネットを検索しだしたらいきなり目が覚めて……え〜、またこれ、夢に騙されるいつものパターンっかぁ……ってなったので、リアルでも検索してみたんだけど、話が馬鹿にデカすぎてCIAにお友達が100人いるというほどの昭和の怪物、伝説級国際ジャーナリスト……の、御子息のほうの先生の仰っていたネイチャーな話とか、人類はコンピュータで神をつくってしまったぁもう終わりだ〜ぁッツ！ といった終末論的な機械仕掛けの神というおはなしとか、果てはおかしな宗教に勧誘されかけそうになったりとか、肝心の目的の、探しているインテリジェンスには辿り着かない……いや、もう、だから……そういう話じゃないんだよ！ ところで、演劇なんかの演出技法としてのデウス・エクス・マキナというのは、どんでん返しと同意義で、いわば機械仕掛けの強引な幕引きということなので、まぁ、初夢オチ？ みたいなものだから、この話にもこれでオチが付いたということ……で、いいよね？
まぁ、余計な事をしていないと死んじゃう病気なので、毎度毎度のとりとめのない枕からの本題に入る。さて、この企画ではLINE SeedをFontLab8でバリアブル化しようというお題で、その過程でFontLab8がバリバリ使いこなせるようになってしまうと言う虫の良いおはなしにしようとしているだけなので、間違ってここへ来てしまったとか、バリアブルフォントって何？ とか思っている人は興味があれば連載のはじめの方から目を通してもらえると助かります。多分何を言ってるかと言うことくらいは簡単に理解出来るようになると思うので……と言ってももう半年ぐらいダラダラとやってしまっているので、ホント申し訳ないのだけれど文章量だけはやたらあるから、ホントに来るつもりもないのに間違ってきてしまって、この手の話に心底興味がないという人の貴重な時間を無駄にするつもりもないので、いますぐ帰って貰ってかまわないのですよ、いや、マジで。まぁ、そういうわけで注意書きも済んだので、話の続きは一応前回までの手続きが終わっているというところから開始する。まぁ、そうすると、作成したファイルは以下のような段階のところまでは到達しているはずだ。おめでとうございます。もう、ほとんど完成しているといっても過言ではない。
同様の作業を比較的シンプルなサンセリフのIBM Plex ver6……まぁ、このフォントもLINE Seedと同様OFL1.1なので、リーガルに関わる問題は六法全書の同人誌を……いや、まぁそういうことはともかく、これ内部にSans JP Ver1という、この夏にサンドルでクリエイトされたLINE Seedと同程度の和文が使えるだけのグリフも抱え込んでいるので比較対象としてはまぁ良いかなと思っただけで本当に他意は無い。まぁ、ともかく、そのくらいのシンプルな書体をもってしても、前回同等な作業をすると以下の通りの有様で、これだと全体の半分以上は再調整が必要になるので下手すると自分で作っちまった方が早い……というほどなのだが、ただ、まぁ、余談を言うとこちらのフォントはGitHubにちゃんとしたソースがあるので、こういうことをしたいなら、それがあるので、こんな逆アセンブルで強引なことをする必要は無い。
まぁ、もっとも普通はどんなにシンプルな書体を選んでも、そういうことをすれば大抵はこういう感じにはなる。なのでweightの差がかなりあるLINE Seedのような書体で、出力された最終形態のフォントファイルを開いて閉じるだけで簡単にバリアブルフォントが出来上がるということのほうが、本当はちょっと異例ではあるのだけれど、まぁそのことからもLINE Seedのデザインが、いかにシンプルな方向を目指してそぎ落としていく方向で設計されているかということだけはよくわかる。ここまで構造がシンプルなのにも関わらず、見ただけでわかるくらいに特徴のある独自性を有するスタイルにもなっているというほどで、造形は本当にシンプルで、ある意味手抜きを疑われるほどの潔さなのだが、それでも、まぁその辺りも含めて考えるとデジタルデバイスが主流になっていく時代との親和性の高い……え、褒めているのか貶しているのかわからない？ いや、何てことを言うんです！ 失礼ですよ……色々と！
と、いうわけで今回はそのあたりのところをなるべく崩さないように注意しながらいろいろと微調整していくという過程で説明していくけど、このあたりの解説を順番にトレースしていけば、誰でも気が付いたときにはもうFontLab8が簡単に使えるようになっているうえにLINE Seedのバリアブルフォントまでもが完成しているという塩梅だ。まぁ、なんかいい感じでしょ？ というか、FontLabのQuickHELP機能はかなり充実しているので、実を言うとソレ見ればわかることは多いからほとんど説明はいらない……と思うかもなんだけど、まぁそれでもレゴを重ねたような見た目のアイコンではビジュアルランゲージが伝わらず意味もよくわからないから、QuickHELPを表示したのに、吹き出しから、Auto layers toggle click if off: makes auto layers云々って言われても、いや、そういうのはわかったけれども、そもそもそのオートレイヤーって何だよ！ ってなるから、まぁそのあたりがわかるようになるようチュートリアルしていこうという感じの趣旨だ……どうなるかはわからないけど……ともかく、そういうことなので、さて、こちらは前回までの準備段階が終わっているという前提で、さっそく作業開始、作業開始。
HelpパネルではFont windowと呼ばれているので一応仮にフォントウインドウとしておくけど、アプリケーションではこの場所で開いたフォントデータのグリフセットをわかりやすいようにセルで分割して表示してくれるというわけだ。まぁ、このあたりはどのフォントエディタでもだいたい同じでお馴染みだろうから大丈夫だよね？
FontLabの場合、さらに、ここと同様の内容をユーザーインターフェースにおける基本的なエレメントを集約しポップアップウインドウにして調整しやすく纏めあげたコンテナにあたるパネルの……とか言ってると長くて煩わしいのでパネルっていうけど、そのFont Mapパネルにも表示することも出来るようになっているので機能をこちらで代替させることができる。フォントウインドウのスペースはグリフを編集しているときには、そっちが優先になるので広い画面のモニターを保有していてグリフセットを確認しながら作業したいという場合なら、パネルならどのパネルも常時開きっぱなしにしておけるので、このFont Mapパネルを置いておいて作業すると便利だ。まぁ、パネルの表示は以下のような感じ。ただし、パネルのデータの画像書き換えは常に四六時中Font Mapパネルが作業内容を監視しているというわけでもないので、作業中のフォントの修正中の図形をグリフセルに反映させるためのリアルタイムな更新には期待しないほうがいい。なので、あれ？ 直っていない？ で、勘違いして、間違ってカチカチ余計な作業を……まぁ、ともかく、そのあたりの注意は必要だけど。
デザインの見た目も一緒なので、機能もわかりやすいよね？ あと、Font Mapではフォントウインドウにない複数のフォントを一緒にプレビューするという機能があるのでそれを使うと以下のような表示になる。
図のように、Fontパネルで選択したフォントから差分がとれるというわけだが、これを見るとLINE Seed Sansの小っちゃい「4」の文字……これは文字に付けられるユニーク名でいうところの「four.dnom」のグリフということになるのだけれど、そのfour.dnomでおかしな事が起きているぞ！ ということが確認出来てしまう。まぁ、ここは本当にちょっと面倒なことになっているので後で手を入れないといけないからそのときに説明する。
他にグリフセルの左下に小っちゃい♥マークが表示されているのが見ればわかるとおもうけど、これはそのグリフの一部もしくは全てが他のグリフの部品を流用して作られているという印で引用元を削除変更してしまうとなにか大変なことが起きることがありますよ、ウフッ、ていうラブリーな警告でもある。その他いろいろセルマークが付くことがあるけれど一番重傷なのはセルのキャプションの下に赤い線が引かれた場合で、Unicodeのコードがその名前と一致していないとか、複数のグリフの名前が競合しているとか、本当に内部で碌でもないことが起きているということを表現している。その場合フォントがまともに出力できない。まぁ、なかには、右肩にちょっと刀傷を負った程度のそれほどたいした事ではない場合でも何かの徴がつくこともあるんだけど、とにかく、何か変わったチェックマークが付いているなぁ〜というようなことを見かけたら、まぁ、そのあたりは、どこがおかしくなっているかはちゃんと確認することだけは必要だ。
表示はどちらもレイヤーごとの表示で、アクティブな部分で表示されている箇所が作業にも影響するので、実作業のためにレイヤーを往来するにはLayer & Mastersパネルでレイヤーを選ぶか、下の図のように左上のアイコンからメニューを表示させれば簡単に行き来出来る。
また、作業中のウインドウでも、初期設定次第だけど、複数のレイヤーの輪廓を並べて表示して、そこのパスや､輪廓をダブルクリックしてレイヤーを駆け廻るとか、まぁ、そのあたりのこともあるので、どこかでドローツールの解説を入れるつもりはあるのでまぁ、なるべくそこで説明する。
さて、それではどこから手を付けても良いけど、とりあえずここでは、最初のグリフとして小文字のｆから手を付ける。今、表示されているから選択されているというレイヤーがたまたまRegularになっているので、その場合、その位置で、Layer & Mastersパネルを開いて確認すると一番下のHeavyのレイヤーだけ背景の表示が赤黒くなるので、こんどは逆にHeavyのレイヤーが選択された状態でここを見ると、他の四つが赤黒くなる。ということで多分ここで何かの問題がおきているのだろうなぁということだけはわかる。まぁ、理由はだいたいあたりがつくので、たいした事ではないのですぐに片が付くけど、それをすると全くチュートリアルにならないので、ここでは少し丁寧に説明するために普段ならそこまで見ないでチャッチャと片付けるようなところまで微に入り細に入り手を入れてやっていく。ちょっとまわりくどいかも知れないけど。まぁ、能書きはともかく。
さて、それでは、ここで背景がビリジアンな他の四つのレイヤーには多数決にかけて問題が無いということにしてしまい、その四つとは何かが合わないのでバックが臙脂色になってしまったのLayerを切り離して問題を解決してしまおう……ということにする場合、Heavyのレイヤーをマスターから外してそのレイヤーを一時的にservice Layerに切り替えるということにする。この作業のトグルは歯車のアイコンの列の中黒をクリックすると歯車に変わるのでこうして切り替える。簡単だね。
さて、そうすると、エラーが消えてVariationパネルにグリフが表示され、この状態ならとりあえずｆの文字はweight軸のあるバリアブルフォントのグリフとして成立することがわかる。ただ、今選択したHeavyのレイヤーはマスターなので、この状態だとこのフォントの全てのグリフからHeavyなマスターが消えてしまったということになるわけで結果としてExtraBoldまでのバリアブルフォントになるということだから問題はなにも解決していないので、この問題を解決してHeavyをserviceLayerからマスターに戻しても、問題がないようにしてあげなければこのフォントからHeavyな表示が消えてしまう……
といっても、実を言うとこの状態でも外挿をとればいくらでもweightはheavyになるのでへっちゃら、平気、屁の河童ではあるのだけれど、それをいうと身も蓋もないうえ。機械が自動で作り出す輪郭でシンギュラリってしまうには……って、いや、まぁ、そういうイカレタ話をするから余談が長くなるのでそこのところは置いておいておいて、それでは、どうやって解決していこうか？ というおはなし。
ところで、バリアブルフォントを制作するに当たって一番肝心なMatchmakerツールの使い方だのVariationパネルの話だのは……まぁ、前にもしたので、あまり細かく突っこみません……というか、ほとんどしないので、そういうところは流していくけど、わからなければ、以前の記事を参照してね。まぁ、それでも、なんだかよくわからないとか要望、希望、リクエストがあればコメント欄へお気軽に……といってもたいした話が出来るわけでは無いけど、それはともかく、さて、それで、まぁ、いつも言うけど、このバリアブルフォントのこの手のエラーは、バリアブルフォントがマスターそれぞれに乗っている図形が一対一に対応していないと機能しないのにそうなっていないでレイヤー毎のノードがマッチしていないのが原因で、今回のようなこの小文字のｆの場合ならHeavyのマスターと他のマスターとの間の輪郭に互換性がなくなってしまっている。まぁ、それが理由でこういうようなことが起きるので、その発生箇所を修正してやる必要がある。
これは、まぁ、普通に考えれば、これだけ軽いweightと、重いweightの間に差があるようなフォントを作ってしまうと、大抵は必ず必然的に発生するという図形の食い込みや重なりが影響している……だろうと簡単に予測できるという、まぁ、そういう感じ。当然だろうけどね。というわけで下の図。
Matchmakerツールをアクティブにした画面。毎度おなじみの図だけれども今回の場合は上の図のようにHeavyを除いた4つのレイヤーなら問題無くバリアブる。ただこれ以上変化すると青の点とオレンジの点が交差してしまうであろうということは、容易に予測でき……って、まぁ見ればわかるよね？ ここからは、説明しにくいから、いま仮に上の図のブルーのノードをそれぞれのweightのN17、オレンジのノードをN18、N17とN18を結んだ輪廓を構成するパスの先にあるノード……図の中の小っちゃい点を順番にN19、N20……とすると、グリフのガウス平面上を青いノードは上向きに橙のノードは下向きのベクトルで移動しているのでこれ以上進むとN18はパスで閉じた塗りつぶされた図形の中……この場合N17とその閉じた図形の垂直に向かい合わせになる左側の輪廓のノード、え〜っと、21，22，23……26？ で合ってるかな、まぁ、いいや今度はN26としておくけれど、そのN26とN17を仮に結んで、その直線を外挿、つまり、左右外側に伸ばしてして作った延長線……グリフのバーの輪廓上側のアウトラインのホリゾンタルな水平線より沈んでいき、ｙ軸方向へマイナスに……つまりN17より低い位置に落ちてｆの字のバーの作る面の中へと食い込んでいって消えてしまう。と、まぁこういうわけだ。
図のようにここへマッチしなかったHeavyの輪郭を追加するとだいぶわかりやすくなると思うけど、N18はｆのバーに入り込んでいるのでHeavyのほうは上の図のように輪郭線を見るとN18が消滅していてHeavyのパス上のN17の次のノードがN19相当になってしまっている。これではノードが一つ足らなくなるのでマッチしないからバリアブらないというわけだ。同じ事がN17-N18の輪廓と向き合ったパス、まぁここではN26-N25とするけど、そこでも起きていて、ここでも今度はN25がめり込んでしまっているのでノードの数が足らなくなって合計で2箇所に支障が出てしまっている。何故そうなるとダメなのかは別のところでしたような……まだ、してなかった？ まぁ、技術思想よりのはなしになるのでここでは割愛するけど、よくわからなければノードのマッチングが破綻するので問題になる程度の理解で全然OK。で、この場合一つの解決方法としてHeavyのN17とN26のある位置に点を一つづつ追加して重点にしてやればいいという話になる。これで理屈の上ではノードの数は一致する。前にも言ったような気もするけど、FontLabではKnife、つまりナイフのツールでノードのポイントをShiftクリックするか、Sciissors、鋏のツールでインクトラップの値をゼロにしてノードをShiftクリックすると、クリックしたそのポイント位置にノードが追加される。
ただ、イラレとかでもそうだけどフォントに限らずベクトル系のデーターで、パス上のまったく同一の位置に同一の役割のノードが幾つも重なってしまうのは基本的にはNGで、表示でも区別が付かなくなるので……もっともFontLabでは、重なっている点と重なっていない点では、ノードの表示が変わるので、注意して見ればわかるようにはなっているけど、まぁそれはそれとして……そういうことが重大なエラーの原因にもなる。で、そういうノードが残って悪いことをしないようにFontLabならClean Up、Glyphsならばパスをクリーニングという作業をすれば悪い子はたちどころに消滅してしまうことにもなるのだけれど、バリアブルフォントの場合ならこういう軽い犯罪には多少のお目こぼしはあるので重なった点を仕様上作ることも出来るようにはなっている……と言うわけ。まぁ、それで、何が言いたいかというと、そういうことなので、バリアブルフォントの制作中は不用意にパスをクリーニングするとノードのマッチが破綻する可能性もありますよ！ と、いう、まぁ、そこはともかく、そういうことで、点を重ねれば、ノードのマッチング問題は解決してしまうので、それならそれでいいといえばいいのだけれど、点をそれ以上移動させたくないからといっても途中でいきなり急ブレーキを踏むようなやり方を取るとフォントのノードが蹈鞴を踏みカーブの動きの自然な遷移を損なうので中間のインスタンスが歪む可能性があり、さらにまた、Heavyより外側のUltra Blackみたいなスタイルに輪廓のラインが振れる場合、ブレーキをかけて運動量をゼロにした箇所は一旦そこでベクトルのデルタがリセットされることにもなるわけで補間がうまくいかなくなってカクッ……いや、まぁ細かくてわかりにくい話はもうともかく、それで、ちゃんとしたバリアブルフォントにしようと思うのであれば、もう少しクレバーな解決方法が要求されるということもある。
で、その方法はどうするかというと、コーナーを切り開いてLoop Cornerを作ってしまうと言うやりかたで、これだと全体の動きはさらに限界を超えて、仮にデータが外挿されても大きくは破綻しないはずということになる。まぁ、以下のような感じだけどね。これまた、以前ならば、普通のフォントデータの場合、塗り潰しの輪廓が交差して、交差したノードが作る面が重なってしまうのは、交差した部分を原点にパスの回転方向が入れ替わるから中が抜けてしまうことになるので、努々御法度ということではあったのだけれどもOpenTypeの仕様ではここも許可されている。まぁ細かい事を言うといろいろな制限限度はあるというのと、仕様に対応していないだの、解釈ミスなどの原因でアプリによってはコーナーに小さい白い三角形を作ってしまう可能性もあるんだけれど、まぁ可能ならばいきなり急ブレーキを踏んでノードとノードがごっつんこするよりは優雅にノード同士がすれ違うやり方のほうが推奨はされてはいるというわけだ。ハウスドルフパレスでノードを流麗にダンスさせるには、テープでステージをバミる位置には当然気を配らないといけないということでもある。
ただ、そうはいっても、これで……まぁ今回は切開する箇所が2箇所で済んでいるからたいしたことにはならないし、切り開いた後にちょっと考えればわかるような位置へノードをちょろっと移動すればすむだけの話なのでなにも問題は無いけれど、もっと複雑になったら困るよね？ そこで、その修繕を簡単にするために、maskレイヤーと#instanceレイヤーを利用するもう少し賢いやりかたもある。maskは前にも言ったけどイラレのような抜型のことでは無く、イラレで言えば選択したパスをガイドにするような感じ。FontLabではToolsメニューのところに項目があるので、まぁそこで選ぶかコマンドMで設置する。#instanceのほうはバリアブルフォントの中間形を表示するもので、補間プロセスのとある瞬間を切り取ったモノだ。まぁ所謂スナップショット。実際には存在しないけれどもそこに或るというシロモノで……なんていう、また、そういう面倒くさい話にしなくても普通にスナップショットでわかるよね？ FontLabのフォントレスマスターの一つで、マスターが存在しない軸位置におけるバリアブルグリフレイヤーになる。まぁ、ともかく、そういうわけなので、これをグリフの補間結果を修正するために利用しようというわけだ。ただ、まぁ、そのはなしは長くなりそうなので、項を改めて解説することにして、やることを簡単な物語に還元すればガイドを見ながら機械で作った輪廓を調整すればより自然な遷移に映るように見せられるからというテクニック的なお話で、そんなに難しい話しをしようとしているわけでは無い。簡単なおはなし。ということで簡単に済むところを簡単に済ませてしまおうということで、そこから順番にやっつけてしまおう。
とりあえずバリアブルフォントにしたときに問題の起こりそうな……というかまぁ、起きているグリフにチェックを入れたのが上の図、鶯色などの茶系統の色が、このいまいったようなタイプに近いエラーで、葡萄色は、これはちょっとややこしいのでここでの説明は最後にする。
それで、この中で一番単純なのは碧色のsemicolonとdivideで、まぁ字で言うと；と÷にあたる文字だ。こういうのはだいたい慣れてくると「どちらもエラーの起こりそうにも無い単純な輪廓で且つ左下に♥がマーキングされていることから他のグリフの部品を二次利用しているだろうということがわかる。呼ばれている元のグリフにエラーが出ていないのと、どちらのグリフも複数のパスで構成されているということから単純に考えればマスターレイヤーによってパスの順番が違っているという可能性が高い」と予測して……と、いうか、まぁ、そういうことを頭の中で一瞬で思考して、「あ〜、いつものヤツだコレ」って言うはなしになる……っていう説明をしていくとかなり面倒くさいな……まぁGlyphsでいったらパスの右肩にこれ見よがしに乗っている数字の順番がレイヤーごとに揃っていないとバリアブルフォントにならないのでダメっていうアレで、作業は単純でフォントウインドウでグリフを選択したらLayer & Mastersパネルを開いてそのマスターレイヤーをチェックしてエレメントの順番を入れ替えれば終了。入れ替え作業はElementパネルを開いてレイヤーの順番をドラッグ・アンド・ドロップで入れ替えるだけなので、Layer & MastersパネルとElementパネルが開いていればフォントウインドウからグリフの編集画面に遷移する必要すら無い。これも簡単。
さて、LINE Seed Sansはベーシックなグリフしか持っていないのにも関わらず小文字のｊのオルタネイト……つまり異体字というやつだけど、それだけはしっかり種類が豊富で、標準グリフ……まぁつまり右から3番目の小文字のｊのグリフを、そのｊの前の文字が§か、gか、jと ｊのオルタネイトのj.alt、j.alt2のケースの場合なら次のｊの文字のグリフは右から2番目の異体字で表示し、bar、parenleft、 backslash、bracketleft、braceleftそれと小文字のqの場合ならば一番右のグリフで代替させるという機能を持っている。これはContextual Alternatesという機能で、日本語にするとコンテキスト代替であってる？ 文脈の前後に合わせてグリフの形態を入れ替えるというような、まぁそういう機能で、文脈といってもAIなことをするわけではないので文字列の組み合わせを見てFeatureが指定のグリフに差し替えているだけ……というかそういうFeatureにするだけだけど、Featureではそこのところをcaltというタグでラベリングする。AならAダッシュ、BならBダッシュと、まぁ同じグリフの仲同士で違う字形に着替えさせるという機能だ。
これがFeatureが誇る異体字の切り替えのケースのひとつで、異体字に関してはゴチャゴチャした別のはなしもあるので最後にもういちどアレするけど、この場合のような隣の人とのトラブルというケースでの字形の代替というものは、若干やってることもやる意義もリガチャーと似ているところがあると思うかもしれないし、カーニングを調整して調整しきれないところをリガチャーして普通に2文字を1文字で代替するというリガチャーの機能を使えばよくない？ と思ったりもするのかもしれないという……まぁ、たまにはそういうところもあったりもするところもあるのかもしれないのだけれども、これが、いろいろな好みや歴史的慣習、各国で異なる正書法……みたいなもうアレがアレで、リガチャを嫌っている人や、使用してはいけないケースなんかもあることもあるので、初手からligatureの機能がオフみたいなことにもなっているという場合もあり……ただ、いくらそうはいってもそれで文字と文字とが無様に重なったり、字の間隔に隙間ができすぎるのも嫌なので、こういうケースでの異体字の切り替えはアプリケーション側でリガチャーの機能がオフになっていても働くようには設計されるため、前後の文字をトリガーに代替字形に切り替えるという、最終的な見た目も同じで一見同じような機能が別の名前で用意されていたりする。
このようにOpenTypeのFeatureでは状況に応じて、一見同じように機能するFeatureが、別々の機能で存在しているということもあるので、いろいろな仕組みややりかたに応じてどこでも同等に機能するようにしなくてはいけないというようなことを考えたりした場合、説明されてもこんなふうに聞いていられなくなるほど面倒くさくて冗長な設計になっている。この仕組みに対して、ちゃんと機能を働かせるならばそこのところは何重にも、複数の箇所に丁寧にトラップを仕掛けていく必要もあったりはする。まぁ、このフォントがそうなっているかどうかは別として、そういう機能が組み込まれているフォントならば前回説明したように、ファイルをオープンしたときに、OpenTypeの機能も一緒に読み込みんでデコードするというところの設定の細かいところはどうだろうが、それがフォントに設置してあればフォントのグリフと一緒にそのプログラムも読みこむと、それが展開されるので、Featuresパネルのどこかに必ずそのプログラムが書かれてはいるはずだ。
で、その場合……まぁ、今回のケースでいえばFontLabのFeaturesパネルの検索窓でcaltのタグを検索すればそれをしているコマンドを発見出来るようにはなっている。展開されているプログラムを見れば、内容はわかるとは思うけど、まぁ、このケースならこちらで再度手を入れ直す必要は無い……はず……だよなぁ、多分。で、まぁ、手を入れ直す必要が無いので、ここまでのはなしはどうでもよくて、今回問題なのはプログラムの方では無く、このバリアブル化したj.alt2……つまり上の図の一番右のグリフでエラーが出てしまっているというところ。
このエラーは……これはもうドットレベルのホントに僅かな部分で一部のノードに破綻が起きるケースがある所為なのだが、実際は多少のエラーは、どこかで辻褄が合っていれば良いから、画面上でうまくいっているように見えて出力にもさほど問題が無いようであればそこは気にしなくても大丈夫……な、はず……って、はずはずはずはずってもう、はずな話が多いんだけど……ホントに大丈夫？ ホント大丈夫だと思うけど。うん、そのはず。結局このはなしは全部どうでも良かったかも知れない。
さて、次に、始めに示した問題の起きているグリフにチェックを入れた図でスイートチョコレートカラー色で塗りつぶした5つのグリフだけれども、それには、それとまったく同じ形で同じUnicodeのCode Pointを共有するグリフが重複していて、ここはなんだかホントにおかしなことになっている……というのが5文字×2の10文字分のｆと何かの組み合わせで、片方が片方をコンポーネントで呼び出しているだけのホントにまったく同じデータなので、俺が何かを見おとしている理由があるという可能性も高いのだけど、多分フォントセットに重複してグリフを保持する意味も無いだろうから呼び出されている元のグリフを残して残りの半分を始末してしまう。このときClassesパネルの定義……ここは、カーニングなどに使うために、サイドベアリングが似たようなグリフをまとめてクラス化しているところで、そこのところはカーニングの話のところで前にしたのでそこの詳細は割愛するけれど、まぁ、ともかく、このclassを定義するフィールドに削除したはずのグリフの名前がもし残ってしまっていると、それはそれで面倒なことにはなるので、グリフを削除するならば、そこも確認して削除する。
Classesパネルを開くと、エラーがある場合わかりやすく表示されるので、その部分を選択して修正。こうしておけばFontLabではある程度は自動的にコードの置き換えや作成、更新が出来るようになっているので、この後はノーコードでも作業は出来る……まぁここのはなしは長くなるのでそのうち纏めてしようとおもっているから、そこはあれなんだけど、ひとつだけ注意しておくと、こういうものも、Classのパネルの修正に失敗するなど、そういった作業のどこかの部分に何かの矛盾が発生していると自動化作業はうまく働かない……逆にいえばそこさえキチンとしておけば、FontLabが出力時に調整するから、ほっておいても大丈夫。ただ、これだけうまくやったつもりになってはいても、やっぱり他で何かがあってfeatureパネルのほうでプログラムの自動更新がうまく働かず「sub リガチャーしたい文字の組み合わせ by 削除したリガチャーのグリフの名前」というようなものが、GSUB featureのリガチャーの指示に残ってしまっているようなら、その部分は「sub リガチャーしたい文字の組み合わせ by 削除しなかったほうのグリフの名前」に書き換えて辻褄だけはあわせておく……って言葉で説明するとホントにわかりにくいな……プログラムだけでいうと、f_f_i、f_f_i.1、f_f_l、f_f_l.1….からf_f_i.1、f_f_l.1….を削除した場合どこかに
sub f f i by f_f_i.1;
sub f f l by f_f_l.1;
sub f f by f_f.1;
sub f i by fi.1;
sub f l by fl.1;みたいなものが残ってしまっていることもあるかもしれないので、
sub f f i by f_f_i;
sub f f l by f_f_l;
sub f f by f_f;
sub f i by fi;
sub f l by fl;ってしてしまえばいいよ〜ん、っていうはなし。あと、それで、こうやって、五人のグリフを葬った後に残されたグリフのUnicode Code Pointが、空になってしまっていては本末転倒なので、そうなってしまっていた場合には、Gryphパネルからクルリンってなっているところをポチッとして、そのCode Pointもちゃんと回復しておくようにする。と、……まぁ、このあたりのはなしがホントに何を言ってるんだかさっぱりわからないという人は、フォントのファイルを開いたときにOpenTypeのfeatureをデコードして機能も一緒に読み込んでいるというような場合、存在するグリフを勝手に削除するといろいろなところで支障をきたすこともあるのでそういうことはやめましょう……というはなしになる。
さて、それで、ここでは、これが、何をしているのかというと、さっき話の中の流れで出てきたリガチャーという仕組みで、リガチャーはサックスなんかのリードを固定する金属製の結束バンドと綴りも意味も同じなので多分語源も同じはず、ffとfiのように複数の文字を繋げて接続し、一つのグリフにした文字のことで、OpenTypeではその仕組み的なところをスクリプトの動作に準じて分類した5種類のリガチャーに対応している……ただ、この話もちょっと込み入っているので、ちゃんと説明しようとすると多分一回では終わらないから、細かい話はまたそのうち。ちなみにリガチャーのことを日本語では合字と呼ぶけど、ここも面倒なことを言い始めると和文では麻と呂二人が合体してボッチの麿の一文字になってしまうような合体文字のことを合字と呼んでいたので、これに元の字を人数分並べて縛るというような結束バンド的な発想は……まぁ、まったくないとはいわないけれど、そういう感じはほとんど無い。おまけにラテン文字では合体した字という意味で合字のことを説明すると＆や？も合字なんだけれど、こちらはリガチャーとは呼ばずパンクチュエーションという仲間に入りパンクチュエーションを日本語に翻訳するとこんどは約物になる……という、ほんとまた面倒くさいことを言い始めたよこの人……まぁそういうことになるので、そこは置いておいて、はなしを続けると、LINE Seed Sansでは、こういうところに、その一連の仕掛けがほどこされているために、このｆのベーシックなリガチャーを利用できるようになっているというわけ。
ｆがリガチャーを必要とするのは、文字の右上の端にあるその独特な形をした鍵型のフックが右隣の隣人と相性が悪くて、オーバーハングして衝突してしまうため、衝突しない組み合わせやデザインで代替しないといけないのだが……個人的感想を言えばｊのオルタネイトといいｆのリガチャーといい、LINE Seedをデザインしたデザイナーはどうも鍵型に対する並々ならぬ拘りと見解が有るのかも知れないと……え？ 誰ですか？ このデザイナーとは上手い酒が飲めそうだなどと言ってる人は。
さて、何を普通と見るのかはアレだけど、通常標準的な文字セットではfiとflの合字があれば十分でエキスパートな文字セットになると追加でff、ffi、fflが用意されるというふうなことにはなっているのだけれど、まぁ、もっとも、ちょっと考えれば自明なことで問題の発生する可能性のある文字の組み合わせはそれだけには留まらないのでエキスパートがこれでは今度は逆に必要不十分にも見えるうえ、カーニングですむならばカーニングでもいいだろうという話にもなる。まぁ、そういうわけなので、この組み合わせの選択があたかも標準仕様とされていてUnicodeで、組み合わせたグリフにわざわざコード番号まで振ってあるというところには合理や必然の理由はほとんどない。初期の機械的な仕様のせいで、なんとなくあやふやにそういうふうになってしまっているという面も少なからずはあるという……まぁ、そういうわけなので、DJRのようにリガチャーを大嫌いと公言しているデザイナーもいるのだけれど……いや、もう､本当に、ここから先はぼざろの山田と同様に余談が止まらなくなるので、この後のはなしはもういいよね？
それで、ｆの話が出てきたので、バリアブルフォントの輪廓を描く方法という最初のｆの話に戻るけど、このようなｆみたいなステムとバーがクロスしているグリフの場合、クロスしたコーナーのクロスした箇所が小さくラウンドしていたりしていると、それはそれでまた話が面倒になるのだけれど、単純に直交しているだけならばバリアブルフォントのグリフを作るのにバーとステムを切り分けて別のパーツにしてしまうという雑な方法で面倒な作業から逃げ切ることもできる。このやりかたも、以前ならばルール違反でフォントエルシャードに棒でボコボコにされたりもしたのだが、いまでは、バリアブルフォント革命によってそういう宗教原理主義独裁体制は崩壊したので横棒と縦棒を別のパーツにして重ねて作ってしまっても大丈夫ということにはなっているから通貨記号等の、ラテン文字に線を引いて記号化したようなグリフのバリアブル化では、こういう形で手を抜くこともできる。まぁ、ただそうはいっても複雑な重複に関してはパスの回転方向での矛盾が解決できなくなったりすることもあるのと、バリアブルで無いフォントでは……これも現状では、可能ならまだ避けた方がよいということもあったりはするのだけれど……まぁとりあえず細かい事は気にしない。
ところで、通貨記号をバリアブルしようとすると、もうひとつ厄介なのはセントとドルで、厄介とは言ってもセントはともかくダラーの綴りのどこにもエスがないのになんで記号に使われている文字がスペインのエスなのかとかいうそういう話では全然なくて、デザインのはなしで、この2つのグリフは、どちらも文字をバーが垂直に貫いてしまっているために文字のweightを太くするとバーがカウンターを埋めてしまって黒い塊になってしまい、なんだかばばっちいのでそうならないように工夫しないといけない……ということから派生する問題だ。通常このための解決方法は大まかに分けて2つあり……あ、いや、まぁ、ばっちくなっても気にしない……という選択肢もないわけではないので三つかも知れないんだけど、まぁそこは置いておいて、いろいろすっ飛ばすと今回の解決方法はまぁ下のようにしてしまおうというわけ。
こんな感じでweightの太いのと、細いのとでグリフのデザインを変えてしまう……というか、もとのデザインがそうなっているので、それに合わせるかたちなんだけど……この場合、こういうことをするために、遷移の途中で別のグリフに切り替える……というコンテキストの代替を機能させる機能を利用してそれを実現するわけで、ブラケットトリックの細かいはなしは、前にも解説したので詳しい説明は割愛するけど、理屈としてはさっき出てきたあれと一緒。まぁ、その作業をするために、セントとドルでコンテキストの代替のためのオルタネイトのグリフを追加する必要があるので、このフォントでは再度、全体のグリフ数が変わってしまうことになる。さっき5つ削除したけど、こんどは2つ追加する形になる。元のグリフに対応するように字形が違うデザインを追加したというかたちにするために、細かい事を言い出すとキリが無いけど、グリフを追加するときは、追加したグリフともとのグリフのサイドベアリングやカーニングなど含め、いろいろなところで矛盾が起こらないように、そのあたりのパラメーターがちゃんと揃っているかどうかはキチンと確認しておく必要がある。その手のパラメーターの確認をミスったりすると、さっき、ややこしいのでここでの説明は最後にするといったような事態を招くことにもなるのだけれど、まぁ、その説明をする前に、こっちのトリックの方を先に仕上げてしまおう。
今もとにするグリフのデザインは以下のような形になっているが、これだとトポロジーが一致しないので途中でチェインが切れて、写像が作れないからバリアブルフォントにならない。
これを､複製したら、複製した方にaltの拡張子……まぁ今回はバリアブルフォント用のオルタネイトということでvarAltという名前にしてあるけど、拡張子にも意味があるので､適当に何でも良いというわけでも無い。まぁ、ここもいろいろあるので、そのうちなんかで解説しておいたほうがいいとは思ってはいるけれど、まぁとりあえずは、そういうことで、複製したグリフと元のグリフでそれぞれが同相写像となるように二セットのグリフを制作する。といっても、それぞれで要らない組み合わせを削除してしまうだけだけど。
それぞれが外挿していってしまう途中をトリックで接続すると上左から下右に自然に遷移するバリアブルフォントになるというわけ。簡単でしょ？ ただ、それぞれで互換性のないグリフを削除したというだけなので、足らない部分を外挿任せで、それに関しては機械の予測にお任せというだけでは、グリフのデザインが切り替わる位置でホントにスムーズに切り替えられるのかというと、そこのところはかなり微妙なので、これではあまりに手抜きが酷すぎると言うことにもなるので、最低でも次のようになるようには考えておく必要がある。
ブルーのグリフをそれぞれのweightに追加する。外挿に頼るよりは補間したほうがまだましだろうということで、出来ればこの間もちゃんと埋めたほうがより品質はGoodになる。ただ、下の行の左端はともかく、上の右端は、これが実用の上では見えないグリフになるとはいえ、バリアブルフォントの機能に完全対応していないシステムからだと見えてしまうこともあるので、そういうときの見栄えが悪いから、もう少し何か工夫したほうがいいのかもしれないのだけれど……まぁ、そこはともかく作業的な話をすると、このブルーの部分を新たに追加修正すればいいということなので、アウトラインの作成方法は……まだ、エディタの説明をしていないけど、このあたりはほかのお絵かきソフトとだいたいは一緒なので、そんなに苦労することは無いと思う。まぁわかりにくければ自分の使いやすいベクトルツールを使って修正してからコピーアンドペーストで戻してあげるという方法であろうが、そういうことも出来るので、まぁ、そこは、ご自由に。矛盾無くパスが書けていればそこはなんでもかまわない。
さて、では、うまく出来るかどうかわからないけど、ややこしいところの説明をしよう。グリフにはそれぞれを識別するためのデータが割り振られていて、細かい話はちゃんと説明しようとすると長くなるので、まぁなんか番号なり名前なりで区別が付くようになっているんだろうなぁ的な理解で良いんだけれど、ある文字を入力したときそれがUnicodeの符号位置のみで表現できるならそれ以上あまり難しいことを考えなくてもいいのでそれでいいのだけれど、さっきも出てきた異体字のｊの場合、Unicodeでは番号だけだと標準字形も、そうでないものも、どちらも同じUnicodeの符号位置の16進数での6A番目の値が割り当てられているから、Unicodeだけだと区別が付かない。そこでコード番号をグループ名と見立てて、それに対応するタグと異体字の番号を組み合わせ、グリフを同定しようというわけ。このフォントの小文字のｊの場合jとj.alt、j.alt2となっているのでまぁフォントエディタ上ではそこで区別を付けているんだろうなぁということは、まぁご想像のとおりでこのaltというのがAlternateつまりはまぁ代替という意味になる。
で、上の図のちっちゃい4に付けられた拡張子、dnomというタグは何かというと、数字の4の異体字のDenominatorsということで、割り算でいうと割る数の分母にあたる文字に相当する。まぁ、分母があれば分子が必要で、そちらはNumeratorsなのでnumrというタグでラベリングする。これがセットで揃っているフォントと機能に対応するアプリがある場合、OpenType Featureが適用されると、slashの前の数字を分子に、続く数字を分母に変えて出力するという仕組みになっていて、まぁ、要は、1と/と4が入力されると¹/₄という出力が得られるという仕掛け。ただ、slashだと斜めの角度が急すぎて見栄えが悪いので、slashとは別に角度の緩いfractionを用意しておいてslashをfractionに置き換えて同様に機能させる……というような一連の流れをFeatureしようとする場合、機能がオンになったら全ての数字を一旦numrに置き換えて並べ、slashが出てきたらfractionに置き換え、fractionに続く数字をdnomに変換し、dnomに続く数字は全部dnomにするということで、
feature frac {
# GSUB feature: Fractions
lookup FRAC {sub slash by fraction;
} FRAC;
lookup UP {sub [zero - nine] by [zero.numr - nine.numr];
} UP;
lookup DOWN {
sub fraction [zero.numr - nine.numr]' by [zero.dnom - nine.dnom];
sub [zero.dnom - nine.dnom] [zero.numr - nine.numr]' by
[zero.dnom - nine.dnom];
} DOWN;
} frac;みたいな感じ。配列の中は面倒なので省略してあるけど、まぁ意味はわかるよね？ ただ、まぁ、これにも問題はあって、ユーザーがこの分数機能を使用していた場合、基本自動適応が推奨されてはいるのだけれど、そうすると2022/12/27みたいなものの処理がぁあゝ々……っていう、まぁ、おかしなことにはなるので、本当はもうちょっとプログラムには工夫が必要になる。
さて、まぁそういう感じなのだけれど、さらに、ここには冗長なトラップがまだあって、Unicodeでは、異体字の分子分母とは別に、分子、分母と似たような……というか、ほぼ一緒の数字グリフにsuperior、inferiorという種類で独立したコードを割り当てる。厳密に言うとこれらは分子分母ではなく上付き下付きの添字のことで上付き数字は分子より高く、下付き数字は分母より低くシフトする必要がある……ような場合もあったりはする。異体字と違って独立したコードが割り振られてはいるものの、コードの並びも123の上付きが16進数でB9, B2, B3……って、この順番なんだよ、何でこうなったのかは知らんけど、で次に0, 4, 5……の上付きが、2070, 2074, 2075……ってなるのでお察しの通りこの間の2071, 2072, 2073にもう一回1，2，3をコピーしろってことなんだろうけど、まぁそういうわけで、冗長かつ面倒なことはいろいろとある。さらにややこしいのがOpenType Featureでは数字の異体字で上付き下付にsupsとsubsを割り当てるので、Unicodeの文字コードに加えてもともとの文字コードにもグループ化されているということにも同時に配慮する必要がある。さらに加えて化学や数学での表記に配慮したベースラインを割ってしまう小っちゃい文字に……こちらはOpenType Featureの異体字でsinfというものが割り当てられていて、合計で……え〜っと、同じようなちっちゃい字を幾つ作れば気が済むんだよ！ って話になる。グリフの形は同じでいいけど厳密に言えばそれぞれシフトする位置が違ったりしていて、非常にややこしい。そういうことで書体によってはこのあたり、どこまで本気にこの茶番に付き合ってあげていられるのかというと、ここのところは温度差がある……のだけれども、まぁ、とりあえずは、そういう気配りが必要になったりもする。
といっても現時点ではこの書体にはそれに付き合うための数字セットすら揃っていないので、それをする意味はほとんど無い。このフォントセットが合成合字の分数グリフ……まぁ、これもこれで、別々のUnicodeポイントがあるんだけど、その分数、½、¼、¾だけを必要としていたためそれを作るためのコンポーネントとして存在しているだけのようなので、フォントセットの中でいわばここだけ盲腸化しているというわけ。fractionのフルセットをちゃんと作るか、フォント出力時に含めない……これはGlyphパネルのNo exportで指定できる……としたほうがグリフセットとしての整合性は良いような気もするのだけれど、まぁ、このあたりはやる気と気分次第ということになる。今回は何もしないけど。ただ、このfour.dnomのHeavyのグリフだけはどうも虫垂炎を拗らせていているようなので、ご覧の通り、他のスタイルの輪廓と水平位置が1文字分ずれてしまっている。なので、その部分だけは一応治療はしておくけど。
さて、このタイプのグリフに手を入れるときには、それが他のグリフの部品として使われているかどうかの確認を怠ると参照先のデータを壊してしまうので、注意は必要になる。自分でも忘れていて時々やってしまうことはあるけど、こういうふうな、他処様の作った書体をいじり倒す場合ならば、なおさらでComponent and Referenceのチェックは欠かさずにすることは大事。この部分はFontLabのパネル表示ではElementパネルからの確認ができる。
それで、まぁ、ともかく、こんな感じで、一連のテキストにするとやたら大変なことをしている感じにみえるかもしれないけど、やってることはたいした事をしていないので、どんなに丁寧にやっても、作業はまぁ高々数時間といったところ、ここまで終わっていればあとは書き出すだけで終了。と、いうわけで次回はそこのところを解説していってこの話を終了する予定。ということでこの続きはまた来年。
この記事が気に入ったらサポートをしてみませんか？