U-32FF plus Variable
そういえば、なんか、今日はフォントの日だそうだけど……期待されてもなにもでない。ここでは、其れ絡みのネタはナニもありません。というか、逆に、ここ、毎回、いつもフォントの日みたいなもんです。まぁ、それはともかく……前に、残念ながらもうレガシーなアプリはベンダーでお世話ができなくなるかも、みたいなことを愚痴っていたりもしていたのだけれど、今月になって、いろいろ……そう、あのFontographerとかも……アップデートされていて、いや〜なんというか、ちょっと感慨深い。フォントの日には全く関係ないけど、前々回の反省も含めて、たまにはいろんなアプリも、忘れないようにいろいろ弄り倒しておくことも必要だということは再認識した次第。フォントの日とは関係ないけど。あぁ、それから令和の合字入りのSource Han Sansのアップデート版がでました。これもフォントの日とは、関係ないけど。これで、U-32FF plus Variableはお役御免です。あと、新しいお札の数字の書体が駄目すぎるってバズってました。駄目な上に、せめて書体くらいは揃えた方が良かったのでは、それともこれが世に言う新手の偽造防止措置なのか？ これもフォントの日とは、関係ないよね？ まぁ、そんな余談はともかく、メイクワァバリエイブルフォントリッスンワン！
さてGlyphsでも半年ぐらい前まではバリアブルフォントの出力機能は、まぁ、おまけでついてきていたようなものだったので、出力するまで期待通りちゃんと動作するかよくわからない……という感じ……だった。いまでも、そんなに変わらないけど、動作確認とかプレビューは、上の図のようにプラグインで、できるものがでてきているので大分よくはなっている。50ユーロぐらいするけど……プレビュー中の設定から新しいインスタンスを作成できたりする機能もあったりするので……まぁ、Glyphsでバリアブルフォントをつくるのであれば便利だとは思う。これは、と、いうか、むしろ必須。もっと早く知りたかったよ。ホント、そうすれば、あんなことや、こんな痛ましいことには……まぁ、それはともかく。
それで、まぁ、そういう事情なので、当時は、っていってもほんのちょっと前までの話なのだけれど……まぁ、余りにもクレイジーな設定で、軸だのマスターだのを弄っていると、ありゃ大変。「ここと、ここと、ここ、忘れないようにメモっておかないと……あと、ココでやった作業はコレで、こっちのはアレだから、こういうふうに動作するはずなので、この辺のアレはコレで……」みたいになって、そのうち、だいたいは、途中でどこが悪かったのかすっかり忘れてしまって、こんどは、もうなんでこんなことしてるんだかという哲学的妄想がよぎったりも、したりも、してしまっていたのだけれども……あ〜、まぁ、とにかく、すべての結果を可視化しておくということが出来ないというのは、作っているほうは、実に、もう、その……まぁ……言いたいことはお察し下さい……。
で、まぁ、そういうコトなので、死屍累々たる有様のGlyphsファイルの山が積み上がっていく、というか積み上がるのだけれど……今でもやってることはそんなに変わってないかも知れない。ただ、まぁ、FontLab VIのおかげで最近はだいぶ、少しは、多少、ちょっとは、少々、ましにはなりました。まぁ、そんな感じのお話。では、どんな感じなのかを前回つくった……と、いうか、そのものを使って解説していきましょう……というスタンスですが……余談が長すぎてその話は次回。
まぁ、その説明の、その前に。
さて、で、この「U-32FF plus Variable」たったの1グリフしかないフォントに何の意味があるのかというと、お立ち会い。実はこれ、たった1文字で全ての書体に対応しようというまぁ、悪魔のような計画の成れの果てだったりするのですよコレが。しかも、異体字とかではなくたったの1グリフで！……「なっ。なんだってぇ——————!!」そう、新時代が到来した今でも人類滅亡の危機は去っては……いや、そういうMMRな話ではないのですよ。
しかし、実際のところ、そんなことが可能ならバリアブルフォントという仕組みは、実はたったの１文字で全てのフォントを、書体を、代替することが可能なのでは……。そう……その通り……。そこに気が付くとは流石だ。そうだな、解説しよう。その秘密というのは……おっと、誰か来たようだ……。
＊ ＊ ＊
いやいや、まぁ、とは言ってもこの話は死亡フラグでもなんでもない。この話を聴いたところで世界の理を破壊してしまったり、物理法則をゆがめてしまったりすることは不可能だ。ましてや、MIBが君の家の玄関を叩くこともない……はず……だ……多分。
さて、原則としてバリアブルフォントはどんなふうに変形しようともグリフは全く同じ輪郭と点で構成される。位置とベクトルが移動するだけだからだ。最もOpentypeの仕様書を読むと、実はストロークを減らしたりアウトラインを大幅に変更したりも、グリフの変形メカニズムを使用することでできるようになるようなことが書いてあったりはするのだけれど「実装が難しく、望ましい結果を得られない」というケーニヒスベルクの橋を渡れといわんばかりの脅し文句も一緒に記載されているところが……この機能に対する悍ましいばかりの厄介な感じを醸し出している。
でも、まぁ、ポンコツな頭をひねるだけでも、ちょっと、他にも、別に、いろいろと、思いつくこともないこともないとはいえないこともないんだけれど……ただ、どれも、これも、こっちはこっちでトリッキー過ぎてあまり実用的とはいえない。そこで、考え方を変え、七つの橋を渡る代わりに特定のインスタンスに対して代替グリフを選択するという方法でバリエーションの変化を補間する……と……こういう方法もOpentypeには用意されているので、其れを使ってパラドックスを回避しようというのがこの話のキモだ。これならオイラーでなくても難問を解決できるし、君の部屋にウィル・スミスとトミー・リー・ジョーンズが突入してくる心配もしなくてよい。
さて、それで、その機能というのは「ユーザーによって選択された特定のバリエーションインスタンスの調整を、FeatureRecord内での 'rvrn' タグを使用して条件付き動作として、OpentypeFeatureのGSUBテーブル内のFeatureVariations tableと一緒に必要なバリエーション代替機能を使用して実装する」という方法だ。特定のバリエーションインスタンスの代替グリフは、FeatureVariations table内の代替機能テーブルに機能テーブルの置換を追加することによって取得できるので、 特定の変動軸値の範囲を指定する条件セットをトリガーとして、置換を行う…………と、まぁ、ちょっと、何を言ってるかわからないだろうから、一般的で、具体的な例で説明しよう。タイトル画像にヒントがある。
上の図のようにバリアブルフォントが書体の太さを極細から極太までサポートするとき、ドルとかセントとかの記号の真ん中の棒は、細い場合はSやCの文字のカウンタの空間を突き抜ける形で無問題なんだけれど、文字が太くなったときにそれをするとカウンタを塗りつぶしてしまいあまりよろしくないので上下にバーをのこしてその間のカウンタをよけるようにデザインする。
このような動作をバリアブルフォントとして実装する場合、互いのトポロジー空間が異なるためうまく同調させることが難しい。そこで、うまくいくようにいろいろズルして、トリッキーな方法に頼る……みたいなことにするよりは、いっそのことデータごと差し替えるというやりかたで対応しようという話が、まぁ、さっきの、坊さんのお経や魔術の呪文みたいな……いや、まぁ、そう……そういうことになる。「平」「成」という文字を打つと「㍻」という合字に勝手変わる……という仕組みと基本一緒……というか、もう、それ、そのもの、illustratorとかで、Opentypeのパネルのところをオン、オフして確認出来る。いまなら、最新のSource Han Sansで試してみれば「令和」と令和の合字がバチバチ切り替わるのが見られると思うけど、まあ、そういうやつ。
それで、この発動条件をOpentypeパネルの任意の合字のオン、オフではなくバリアブルサイズの変更をトリガーにすれば、スライダをびよ〜んって移動するだけでTHUNDERBIRD ARE GO!するフォントも作れるかも……。
っていうのが発端。で、まあ、具体的にはどうするかというと
OpentypeFeatureにrvrnを追加して、
feature rvrn {
sub [代替グリフ] by [元のグリフ];
｝rvrn;のような記述が必要なので、下の図の場合なら代替グリフを作成して、「セントの代替グリフ」ということがわかるような適当な名前を付けておく、あ〜、まぁ、勘違いする人もいないとおもうけど本当に日本語で「セントの代替グリフ」と打ち込まないように、sub [なんちゃら] by のそこのところの、適当であれば何でもいいということだからね。ただ、これも、まぁ、あんまり適当すぎると後でなんだかわからなくなるので……まぁ、その辺りも適当に……それで、まぁ、そこに、代替グリフとなるフォントを作成してしまおう、ということ。で、THUNDERBIRD ARE GO!の場合は、同じ調子でドンドン入れ子にしてしまえれば上手くいきそうな気がしてきたぞ……基本的な考え方は同じだし……まぁ、グリフが軸上異なる時間で切り替わる場合は、異なるlookupにグループ化する必要は、ある……のか？
lookup RVRN1 {
sub fore by five；
｝RVRN1；
lookup RVRN2 {
sub three by fore；
｝RVRN2;・・・・・・・・・・・
それで、まぁ、ここまで、作ったフォントに問題がなければ、これらの切り替えがいつ行われるかという条件を書いたテーブルを編集する。GSUBからrvrnをひっぺがして、
<FeatureRecord index="〜">
<FeatureTag value="rvrn"/>
<Feature>
</Feature>
</FeatureRecord>〜のところは、rvrnがフォントの中で順序づけられている値で、ここのところはいろいろ。ケースによって違う。
<FeatureVariations>
<!-- GSUBのバージョン -->
<Version value="0x00010001"/>
<FeatureVariationRecord index="0">
<ConditionSet>
<!-- 条件1 -->
<ConditionTable index="軸の番号0" Format="1">
<AxisIndex value="軸の番号0"/>
<FilterRangeMinValue value="置換が有効になる場所の数値の小さい方"/>
<FilterRangeMaxValue value="置換が有効になる場所の数値の大きい方"/>
</ConditionTable>
</ConditionSet>
<FeatureTableSubstitution>
<Version value="0x00010000"/>
<!-- 代替1 -->
<SubstitutionRecord index="0">
<FeatureIndex value="〜（ｒｖｒｎ機能のID番号で上の〜と一緒）"/>
<Feature>
<!-- 置換グループ1 -->
<LookupListIndex index="0" value="置換グループを表すLookupの番号"/>
</Feature>
</SubstitutionRecord>
</FeatureTableSubstitution>
</FeatureVariationRecord>
</FeatureVariations>と、まぁ、具体的な説明になっても、これはこれで、ややこしいうえに、一歩間違えると面倒なことになりそうな予感しかない……。条件テーブルでデザイン変動軸の範囲の設定(fvar)とかも、う〜ん、これ、正規化スケールで-1〜1の中にマッピング……AxisIndexはaxisCountより小さく……無効の場合はこのテーブルの……FilterRangeMinValue＜FilterRangeMaxValueが……って、これ全部手作業したらまた、おかしなことになりそうだなぁ……だいたい、条件文は入れ子にしてチャンと動くのか？ 不安。
とはいえ、＄とか¢とかの場合は、やること、やっていることは、もう、まったく単純で、途中までカウンタ串刺しのデザインで太くしていって、途中からカウンタ空きのデザインに切り替えますよ……ってことだけなんだけれど。
それでも、それを、ちゃんと動作するように作ろうとすると……まぁ、なんかこう、いろいろとあるので……そういえば、noteで、OpentypeTableの解説をしてくれている人もいたなぁ……こんな不真面目な解説読むより、ちゃんとしたもので学習してくれた方がいいのだけれど……。まぁ、それでも、しかし、投げっぱなしも寝覚めが悪い。そこで、実はプログラムなんて一行も書けなくてもなんとかする方法もある。そう、Glyphsならね。
まぁ、ここから先はGlyphsを、あるていど使えているだろうという仮定からスタートするので、Glyphsの使い方とか、そういうのはイロイロすっ飛ばしてGlyphsでバリアブルなフォントを作成中にそういうことが必要になりました……という前提で話を始めると、さて、まず単純なバリアブルフォントを作るために、ということで、上の図のように2軸のレイヤーを準備したら、それぞれのボールドとライトのレイヤーにさらにサブレイヤーを追加する。
そこに、もとのレイヤーの名前に続けてスペース、角括弧、変数、角括弧閉じる。という名前を付けてこれを代替グリフ用のレイヤーとして作成する。もちろん代替グリフ同士は輪郭と点の数が一致することが条件だが、代替グリフと元のグリフとの関係は全く無視してしまっても構わない。もとのグリフは「A」だけど、代替グリフは「B」でした、ということになっていても一向に構わない。THUNDERBIRD ARE GO! というわけだ。
まぁ、ともかく、それで、この設定でバリアブルフォントを書き出すと、バリアブルの値の低い方からスライダを移動していって、ある値を超えたところ……上の図の例で言えば220という数値を超えたところで、一瞬で代替グリフに切り替わるという荒技を見せてくれるフォントが完成するというわけ。Glyphsが後ろでTableやらFeatureやらをよきにとり計らってくれるので、もう、お茶を飲む暇も無いほど簡単に、下の図のような点線のところで上下が一気に切り替わるというバリアブルフォントのグリフが自動的に完成する。
素晴らしい！ で、FontLabのほうは、この書き出しを自動でやってくれるような親切さはないので、まぁ、さっきのような説明を頭っからしていく必要があるってわけなんだけれど。でも、まぁ、こういうのは、ちゃんと探せばどっかに、なんかは、必ず、あるはず……なんだろうけどね……多分。まぁ、それは、ともかく。
しかし、で、まぁ、ここからが、本題なんだけど。コレを思いついたときに「そんなふうにグリフの切り替えが可能ならデザインの自由度が一気に上がるじゃん……」と、思ってウホウホしてしまったんだけど、当然そんな旨い話がそんじょそこらに転がっているというワケはない。いろいろと制約やら仕様の問題やら、限度っていうものは存在する。そのうえ、まぁ、ちょっと上で解説したみたいなことになっているので……ホント、そういうことを考慮しないままに作業を開始すると碌なコトにならない。というか、酷いことになってるんだけど……もう、だらだらと理解しがたいテキストの仕様書と格闘した結果、結論として最後に「……というのは本質的に間違っている」で、〆られた気分。蓮實重彥かよお前はって思わず突っ込んでしまいそうになる。それで、まぁ、だから、成れの果てっていうのは、そういうことなので、別の意味で、死亡フラグがたっていました……。というオチの話なのだけれど……いや、もう、ココまでが、いつもの雑談です……さて、今回非常にたちが悪いのは、もう、本篇に見せかけての雑談、これは……これで……こういうわけなので、こんなことなら、こんな碌でもないことが閃く前にトミー・リー・ジョーンズにピカッとしてもらいたかったよホント。
この記事が気に入ったらサポートをしてみませんか？