FontLab 8：手書き風フォントの作り方
何かをデザインするにあたって、その作業においてコンセプトや雰囲気、スタイルなどなど、そういったものに一貫性があるかどうかということは、ある意味デザインという作業における基本のキなので、そのことについてとりたててなにか特別に重要なことでもあるかのようにあえて特筆して云うようなおはなしでも無いような気もするのだけれど、最近では「デザインでスタイル、ユーザーインターフェイス等々に一貫性を持たせるルール」というような意味で「トンマナ」というどうにも間抜けな語感の略語がビジネス用語として定着している。
誰が言い出したのかよくわからないので、AIに尋ねるとtone and mannerの略語で、過去に業界で使われていた言葉が云々みたいな話もするのだが、発案者については不明だ。そもそもの話で言えば英語圏でトンマナの意味でtone and mannerなどと言ってるというアレも人も記憶も皆無で、プロフェッショナルや業界人の間でも「デザインをデザインする」などという、まるで古の昔の武士の侍が馬から落ちて落馬して女の婦人に笑われて赤い顔して赤面し家に帰って帰宅……して切腹するかのようなケースの場合の言い換えの換言が必要必須になるというような事例の出来事が存在するなどということが些か考えづらいので……まぁ、このあたりの解説は、どういうふうに考えてもどうにも怪しさ満点だ。
個人的には意地悪な先輩クリエイターかデザイン学校の先生が、毎回間抜けな要求ばかりしてくる代理店の連中か、やる気の無いノロマな学生を馬鹿にして揶揄うつもりで、音が「頓馬な」などという昭和の人間にしかわからないような間抜けやノロマを指し示す意味を内包する語彙に重なるということでtone and mannerなどというあきらかに怪しげな横文字の専門造語を捏造したのだが、これが基本当たり前のことを言っているだけなのに造語としては思った以上によく出来ていたためか、ネット上で拡散され続けエコーチェンバーしていくことにより、恐らく頓馬という言葉を聞いたことすらないだろうという知ったかぶりの連中に「知らないと恥ずかしい業界専門用語です」とかと独自解説されるようになるまでに至り、いまやAIですら誤認識するような言葉となり、頓馬なことに造語した本人の意図とは真逆の意味に定着してしまったのではないか……と疑ってはいるのだが……まぁ、意図は伝わるし、覚え立ての専門用語で精一杯背伸びしている感じが微笑ましいので別に使うなとは言わないけれど、但し、よく意味を考えずに校正紙に赤字で大きく丸を付けて「デザイン、トンマナで」みたいなふわふわな指示をすると、クリエイターによっては「頓馬とは何だ！ 馬鹿野郎ここは意図があってこうなっているんだよ！ アマチュアがプロにデザインの基礎がまったく出来てないという指摘をするったぁ良い度胸だ、喧嘩売ってんのか！ この野郎！ 表に出ろ！」みたいな感じになってぶち切れてしまうというような事例もあるかも知れないので……ホント使う相手と使いどころにはちゃんと注意したほうがいい。まぁ、これは老婆心ではあるのだけれどね。
そういうわけで、こんな感じに色々な人の琴線を破壊してしまうと言うことにもなるかもしれないというようなこともあるので、予め注意して置くけど、今回も適当なことしか言ってないから、毎回言うけどまともな話はまともなところで、ホント、お願いしますよ。
さて、注意書きも済んだところで、今回は手書きの文字をフォントにしようというおはなし。ただ、前にも言ったかも知れないけど、Emil Ruder先生も仰るとおりで基本的に書き文字を活字化するというのはどうやったって頓馬な話にはなるので、まぁ、やることはアレなことではあるのだけれど、技術的な進歩によってある程度の部分まではそれらしく表現することが可能になってきてはいるということなので、まぁ、そのあたりのチャレンジをしようという、そういう趣旨。大丈夫？ 附いてきてる？
さて、それで、一昔前では書き文字をフォント化するといっても……こんなものは描いた文字をスキャンして輪廓を生成するだけのことだろう……と、まぁ、そういう単純なことにしたとしても……いろいろと下準備が必要だったりはしたのだけれど、今では書いた文字をフォントにするだけならタッチインターフェイス対応のiFontMakerのようなアプリやら、テンプレートを送るとフォント化するcalligraphr、Web画面をなぞるだけのkidpofyのような簡単サービスから、果てはFontworksのAI JIMOJIのようなひらがな46文字を書くだけで、そのデータから軽く200を超えるキャラクターを持つOpenTypeフォントを勝手に自動生成してくれるようなWebサービスまで、選り取り見取りといろいろあるので、漫画家からゲーム作家からアイドルから子供から爺さん婆さんまで、どんな人でも簡単にフォントが作れるような時代になったため、最近では日本語でも結構な収録文字数を誇る手書きのフリーフォントも増えてきていて、そういう意味では書き文字でフォントを作成するというその入口のところの敷居は過去よりだいぶ低くはなっているのだけれど、スキャンしたものをアウトライン化するにしろ、この手の簡単なアプリやサービスを利用するにせよ、その方法では、結論を言えば現代でもまだまだフォントとしてはちょっと原始的な……まぁ、なんだ、つまりは、どのサービスを利用してもかなりの割合で山のようにノードのあるポンコツなデータが出来上がる……ただ、まぁ、これはこれでフォントとしては全然使えるので、たいした問題ではないから、そこはそれでもいいのだけれど、そもそもをいえば基本的には一つのキャラクターに一つの文字という活字システムの仕組みと手書きの文字との相性は最悪で、手書き風フォントはあくまで手書き風フォントというジャンルになるので、手書き風フォントだからといって、それが手書きの文字を本当にシミュレートしているということにはまったくならないだろうということは……まぁ言うまでも無い。
それで、まぁこういうことなので、俳優の書き文字から御老人の筆蹟まで、それをアイデアのソースとして利用して活字を作成するという方法論の問題とツールとして手書きの筆致を利用するというテクニックのおはなし、書き文字そのものをシミュレートして書き文字フォントを作成しようとするというそういうこととの間には大きな溝が横たわっているのだが……ただ、それが駄目という話では無いので、この話を誤解されないように説明しようとすると長くなるから……まぁ、あれなんだけど……単純にタイポグラフィ的なことだけで説明すると、書き文字と書き文字風フォントでは、どんなにそれっぽく装って見せてもどちらを使うのかによってデザインからうける印象がまったく別になってしまうというケースはある。
このあたりは、一例を挙げると、サブスクリプションを頑なに拒んでいる某日本人アーティストのアルバムでタイポグラフィだけでデザインされたシティポップの名盤が復刻されたときに高原宏のデザインコンセプトだけはそのままなのに書き文字だったところだけをわざわざ書き文字風フォントに置き換えたために肝心のタイポグラフィをメインにデザインしました……というコンセプトの部分がブレブレになってしまい……あと、細かいことを言うとアポストロフィーも字の詰めもなんかおかしいとかいろいろとそういうこともあったりはするんだけど、まぁ、そこはいいとしても、そういうことで、結果としてデザインがなんか中途半端で非常に残念なことになってしまっているというようなことがある……ただまぁ、そうなった理由は知らないからそのことを批判したり非難したり駄目といいたいわけではないのだけれど。ただし、単純にデザインを見た印象だけで語るとそういう感じに見えてしまっているということはあるので、まぁ、そう感じてしまうくらいには、30周年記念ニューリマスター盤がオリジナル版と比較すると廉価版に見えてしまうくらいには安っぽく出来上がってしまっているような印象の感じになり、結果としてデザインの所為でいろいろな人々の考えるプロダクトの価値や評価を大きく毀損してしまうような残念な影響をもたらす……ように感じさせてしまうという、そういったことの要因の一因にもなってしまうというようなことも……まぁ、あったりしたりすることはある。
で、まぁ、書き文字風フォントをワンポイントで使うというならともかく、長文の書き文字が必要なところに書き文字風フォントを使うと往々にして駄目なことになってしまうからやめたほうがいいといわれる理由がこういうところにもあるということはあるのだけれど……ただ、いつも云うけど、こんなおはなしも関係者全員がそんなことは気にもしないと仰るのであれば、こんな細かいことなんかホントどうでもいいんだよ。
さて、でもまぁ、ともかくそういうわけで、つまりは、根本的な問題として、そうならないように手書きの文字をフォントでシミュレートする場合、どの文字ひとつとっても一つには定まらないという手書きの持つアログリフ性という特徴をどうするかという話をヌキにしては語れないと云うそういう側面もあるから、これを無理矢理フォントで忠実に再現しようと思ったらシステム上ではフォントデータに、必要な文字数分だけの膨大な数の異体字を抱え込んで、ようやくやっとそれっぽく見えるようになるスタートラインには立てるだろう……というようなおはなしになることもあるにはあるのだけれど、ただ、まぁ、実際のトコロその「膨大な数」の量によっては……そこまでするならフォントにする意味はほとんど無い、というところの結論にまで至ってしまうので、ぶっちゃけ書いた方が早い。ここら辺が書き文字をトレースしてフォントを作ってもタイポグラフィとしてはいかがなものかというようなおはなしにもなるというところの原因の一端でもあるのだけれど、ただ、今そういうことを言い出すとお話は盛大に卓袱台返しにはなるので、そういうこともあるにはあるけど、それも踏まえた上でそのおはなしは一端脇においておいて、さて、手書き風のフォントにいろいろとトリックを駆使してもう少しイカした工夫することは出来ないのか？ というところの内容が今回のはなしのキモになる。え？ イカれた工夫？ まぁ、そういうところはどうでもいいんだよ！ まぁ、とにかく極端な比喩で言えばお店の本格中華麺が食べたいのだけれど、出かけるのが面倒なのでカップヌードルでも充分という主張だって無いわけでは無いけれど、それでもできればお店のように本格的で美味しい高級カップ麺に……いや、まぁ、そんなこともともかくとして、というようなことで、そのためのトリックとして、毎度おなじみの手品の種の Opentype Feature のお出ましということになる……まぁ、ホント言い訳だけは毎回長くてまわりくどいのだけれど、ここからが実際の本題になる。
それで、最初からネタバレすると今回作成したのは以下のフォント。まぁ、数字だけしかないので、用途が絞られるけど、こんな感じの書体。常識的な量に収まる複数の異体字を組み込んでランダムに表示させるプログラムを駆使し、簡単に手書きっぽさを表現しようと試みている。
ということで、タイトルでも使われているこの文字は……まぁ、ただの手書き風フォントなんだけど、同じキャラクターに対して複数の異体字形がランダムに並ぶので、フォントではなく手書きしたかのようにも見えるけど……んん？ なんかよく見ると、ところどころがいろいろと微妙におかしな雰囲気に……あぁ！ やっぱりフォントじゃねえか！ というフォント。出かけるのは面倒くさいけど、なるべく簡単に高級カップ麺に近づくように……というわけで、このあたりの解説とともにこのフォントの作り方をFontLab 8のチュートリアルからはじめよう。
とりあえず数字と記号をいくつか。後で気が変わるかも知れないけど、カンマ、ピリオド、あと0から9までの数字があればなんとかなるでしょ……というスタンス。FontLab8ではストロークを作成するためにフリーハンドでカリグラフィックに輪廓が塗りつぶされたパスを生成するBrushツール、フリーハンドにパスを作成するPencilツール、直線やスムースな曲線でパスをドローするRapidツール、イラレのようなベジェ曲線でパスを描画するPenツールの4つのツールが存在するが、今回はサインペンで殴り書きした骨骼をスキャンしてPenツールでトレースしているだけ。下の図のような感じになる。
今回のようなPenツールの使い方をする場合、あまりきちんとトレースすることに拘りすぎてノードの数を増やしすぎない……ということは大事。なるべく少ないノードでトレースする。上の例だと左の緑色のノードも……まぁ、必要無いので削ってしまって構わない。これは文字の筆記速度を考慮すれば書き文字のトレースでは正確さよりは勢いのほうが大事になるだろうというスタンス。まぁ、仮に手書きされる文字のラインの書かれる速度をだいたい１インチ秒として計算しても、時速90㍍ちょっと？ 新海誠の桜の花弁の落下速度の半分ぐらいのスピードなので、そう聞くとそこまで早くないような気もするかも知れないけど、フォントデータを原寸で作る人はいないので、実際はかなり拡大したラインを見ているわけだからそこを換算して考えると運動速度は、目の前を自転車が駆け抜けるくらいの速度でラインが描かれていくような…………え？ なんか詭弁に聞こえる？ うん、まぁ、詭弁といわれれば、そうかもしれないんだけど、こういうのは何事もイメージなんだよね。とにかく速度的なことを考慮すれば書き文字のトレースでは正確さよりは勢いのほうが大事だということもあるという感じで感覚的にそう理解してもらえればいいということだけなんだけど、まぁなんか、そういうイメージ……ただ、今回は考慮していないけど線の擦れや滲みガタつきを考える場合は、勿論その分のノードが必要になるので、当然その限りでは無いのだけれど、それでもやっぱりその場合でも、根本的には骨骼に当たるラインの勢いを殺してしまうと残念な感じにはなるので描画における「絶対ベクトル感」というか……まぁ適当に言ってるだけなんだけど、文字のストロークのキネティックな方向どう落とし込んでいくかに関しては……まぁそういう感覚は大事になる。勿論、画像をスキャンしてアウトラインを抽出するだけの簡単なお仕事ですむのなら、そんなこたぁホントど〜でもイイかもしれないのだけれど。
あと、もうひとつ大事なこととして基本的にフォントの数字はゼロから始めてなるべく同じ字幅で設計していかないとあとでその数字で表を組んだりしたときに乱雑になったりして、これはこれでめちゃめちゃなことになるから、フォントで数字を作る場合はなるべくそういうところにもちゃんと気を配っているほうが良いことは良いのだけれど、今回はあまり気にしてないのでそういうところも良い子は真似しちゃダメだよ。まぁ、とはいっても、それでもある程度のバランスはとる必要はあるのでそのあたりは匙加減。いくら俺の字が汚いとは言っても1なのか7なのかわからないということになるとただでさえ実用的ではないフォントがあまりに非現実的にはなるのでその辺りは工夫したりはしている。下の図のように全ての文字で全ての文字を挟んだテキストを用意してそれを見ながら細部を調整する。
さて、まぁそこはともかくとして、とりあえず骨骼が決まったらそこに肉……つまり仮想の輪郭線を付けてフィニッシュすると文字が出来上がる。生成した骨骼の線にBrushツールのパネルを開いて、それで輪廓を生成すると、比較的簡単に揺らぎのあるラインを生成することはできるけど、今回はサインペンかボールペンで書いたような筆蹟をシミュレーションする感じにしたためStrokeパネルだけで輪廓の肉付けを行っている。フォントの制作にFontLabではなくGlyphsを使っているユーザーは教育関係以外は有料になるけどLTTR/INKのストロークエンジンというプラグインがあるので、それを使えばFontLabのツールと同じようにストロークから輪廓を非破壊に生成することができる……まぁ、そのあたりは以前も話したので詳細は省くけど。
Strokeパネルは、線の太さ、角の形状、始点終点のキャップの形、色などのプロパティを調整して自動的に輪廓を生成するためのツール。このストロークエレメントをパワーストローク化すると出力されるフォントはここで作られた輪廓から必要なノードを自動生成する。この作業はブラックボックスなので、そういうふうにフォントを出力すると、どういうデータが整正されるかは編集画面を見ているだけではわからない。実データの輪廓のノードを細部にわたって細か〜くコントロール及び調整したいという欲求のある場合には……いや、まぁ、まったく出来ないわけじゃ無いんだけど、まぁ基本的にはそういう道具ではないのでそういうことにはまったく不向きなツールなのだが、大雑把に輪廓を捉えてフォント全体を調整しようとする場合には線の太さやキャップの形状が簡単に変更出来るのでそこは便利。
またデータの可逆性は失われるけど後からFlatten layerするか、Expand strokeなどでストロークのアウトラインをとってしまえば、ご想像通り今まで通りの普通の作業で輪廓のノードを微調整をすることはできるので、最初から最後までをStroke頼みにはしないというスタンスで作業の省力化や効率化の道具としてみれば……まぁ、細かくは説明しないけど、そういうふうな使い方も出来る。こうして作った輪廓にさらにStrokeパネルでプロパティを再掛けすると袋文字や二重袋文字、過剰梱包文字などをいとも簡単にどんどん作成することはできるのだけれど、やり過ぎて要素がこんがらがってしまい後から悲鳴をあげてしまうことのないようにElementパネルはその都度ちゃんと確認しておくという習慣を付けておくことは大事。実はいつも思っていることなのだけれどillustratorとかでも何でもこの手のハイアーキテクチャーなツールっていろいろなところがどんどんと複雑化して出力のコンパイルとはまったく無関係なデータがどんどん出来てくるから、メインの画面だけを見ていると工程の間違いに気が付かなかったりすることが偶にあるんだよね。共通アプリケーションサウンドガイドラインみたいなものを用意して、そこからグニュッとかパスッとかポヨンとかピロロンとかブブッとかポコッとかベリッとかボソボソッとかガサゴソっとかって、まぁ何でも良いのだけれど作業のその都度行動に合わせて色々な音が組み合わせで鳴るようになっているとヒヤリハットが抑制されて、その場その場でミスに気が付きやすくなるので便利だと思うんだけどね……ビリッ！ガリガリ！ガガガッ！って、あぁ今鳴ってはいけない音がした！ やっちまったぞ！ って感じに……いや、抑制どころかハインリッヒさんがやって来てるじゃねえか。
さて、まぁ、それで、この段階では汚い手書きをみせられて、それをただ単純に活字化しただけでお湯を掛けて３分間程度のお仕事に見えるかも知れないから、これだけだと流石にインテリジェンスが足らないので、乾燥野菜くずこと加薬を追加して、ちょっと高そうに装える手書き風フォントに改造していく……って、まぁ、そのわかりにくい喩えはともかく、それで、基本のグリフが用意できたら、このグリフをコピーして手書きのための複数のパターンを追加する……今回は単純に0から9までの数字のグリフ10種類のみで、それをしようとしているんだけど。まぁ、このあたりを簡単にしようと思って、現状ここまではノードの少ないStrokeを利用して文字を作っていたということもあるので、このあと実は異体字の作成はほんのチョロッとした作業で終了する……で、ここからはそのためのちょっとした仕込みを行っておく。その仕込みは何かというと、以前にも少し説明したことがあったような気がしているけど、まぁいいや……もう一回説明すると、ここで、データを非破壊的に変換するというFontLabの誇るツールの仕組みのデルタフィルターというものを設置する。
デルタフィルターを利用するとパワーストロークが作成するであろうブラックボックスなデータの仮想的な輪廓のノードを可視化して、そのノードを新しい位置に移動したり、それに応じて他のノードの位置を補間するということも出来るので、こういうバリエーションをどんどん増やしていこうとする場合非常に簡単便利に使えるツール。もとのデータを破壊しないのと、移動がリアルタイムに可視化されるので、あとでネタばらしをするけどバリアブルフォントの作成にはうってつけ。ただ、まぁ、まだわりとバギーなツールではあるので、あんまりやり過ぎると時計がグルグル回ったまま戻ってこなくなったりすることがあるから……ちょっとした注意とコツが必要になる。ただ、その半分くらいは俺が悪かったりもするんだけど、そこはともかく、そんなこんなでコピーしたグリフにそれぞれ.cv01, cv02, .cv03 というサフィックスを追加してそれぞれのグリフを作成したら、デルタで輪廓を調整する。拡張子はまぁ、全部を全部、自己責任で手作業するつもりなら別に何でもいいんだけど、フォントエディターに関わるお約束ごとに則ってネーミングしておくと、面倒が少しだけ軽減されるようにはなっている。今回はCharacter Variant という意味なのでcvXX。Opentypeではどんなワタナベさんがやって来ても大丈夫なように、ひとつのキャラクターそれぞれに対してVariant 01から99まで最大で99の異体字グリフを追加してもいいという仕様になっているからその仕様に沿ったネーム付けをする場合はこのようにする。というわけで、気の済むまで好きなだけバリアントを作成してもいいのだけど……まぁ、ここは余裕と時間さえあれば幾らでもお好きにどうぞ。
ともかく手順としてまとめると、XXの数字は順番に、新しい.cvXXを作って、その作った新しい.cvXXが空ならエレメント参照もしくはコンポーネントを挿入し、挿入したオブジェクトに鍵がかかっていたらelementパネルからロックを解除してからelementメニューでデルタフィルターを追加して……ってまぁそういう感じの作業。これで後はデルタの調整だけでいくらでもバリエーションを追加できるって感じだから、まぁ簡単でしょ？ さて、結果は以下の通り。こうやって追加したグリフの筺の中のデザインは、デルタをもっと派手に動かしても、デルタフィルターを使用するなどという、そういうぬるま湯につかったような小細工を使わずに、手作業でガンガン修正するなり、あるいはまったく違うデータの字形をデザインしてそれに置き換えるのでも、そこのところは実はホントはどうでもいいんだけど、今回はこの後のことがあるので、ぬるま湯につかったようなやりかたをしている。だからFontLabではなくGlyphsで作業する場合や、もうちょっと真面目に仕事をする場合はデルタ云々のおはなしのところはすっ飛ばしても大丈夫。まぁ、とにかくここではグリフに複数のCharacter Variantを作りましょうという趣旨で、そこが理解出来れば問題はない。
さて、fontに3つの異体字グループを追加したので、これを OpentypeFeatureのCharacter VariantとしてOpentypeに認識させるためにOpentypeFeatureにその旨を記述する。雑に説明するとFeaturesの記述はcvxxにキャラクターバリエーションを指定して、Stylistic Alternatesことsaltに、おのおの sub 数字 from [数字.cv01 数字.cv02 数字.cv03]; という記述をキャラクターの分だけ追加し、追加したFeatureをaaltにリストすれば、これで異体字の設置作業は終了する……のだけれど、このあたりは、よくわからなくても適切な拡張子とグリフの名前付けさえ間違えなければあとはGlyphsやらFontLabが勝手に処理してくれるところだから大丈夫。さて、ここからが本当の本番だけど、ここでようやく、OpentypeFeatureのカスタマイズの出番になる。
まずは作ったCharacter Variantごとにクラス分けをして括っておく、このあたりの話は前々回に説明した内容に被るので、何をしているのかよくわからないという場合、詳細はそっちで見て貰うと理解がおよぶと思うけど……
まぁ、要はリストに＠でクラスネームをつけておくというわけだ。今回は、
@number = [zero one two three four five six seven eight nine];
@num_cv01 = [zero.cv01 one.cv01 two.cv01 three.cv01 four.cv01 five.cv01 six.cv01 seven.cv01 eight.cv01 nine.cv01];
@num_cv02 = [zero.cv02 one.cv02 two.cv02 three.cv02 four.cv02 five.cv02 six.cv02 seven.cv02 eight.cv02 nine.cv02];
@num_cv03 = [zero.cv03 one.cv03 two.cv03 three.cv03 four.cv03 five.cv03 six.cv03 seven.cv03 eight.cv03 nine.cv03];
とでもしておくけど、まぁこれでいったん準備完了。
この＠で定義した、@number、@num_cv01、@num_cv02、@num_cv03の4種類の異体字を、テキスト打ったときにランダムに表示させるプログラムを考える……というのが趣旨だけれど、ただ、残念なことにOpentypeFeatureにはランダム関数を出力する仕組みがないので、その部分を自前で用意する必要がある。まずは単純なプログラムから。
sub @number @number' by @num_cv01;
sub @num_cv01 @number' by @num_cv02;
sub @num_cv02 @number' by @num_cv03;
という感じ。これは4つの異体字のグループを本当に単純にサイクルさせるだけの仕組みだ。あまりにも単純過ぎると思うかも知れないけど、通常文字列のテキスト自体はランダムに並び続けるため、こんな単純な仕組みでも、パッと見は10種類の数字が4つのクラスの中でちゃんとランダムにシャッフルされているようには見える……見えるよね？ 見えるんじゃないかな……まぁ、とにかく図にすると以下のように文字列が伸びる度に次々と文字が置換されその4つの状態がループしていくという仕掛け。ランダムに見えてくるよね？
ただし、これには問題もあって、こうした場合4文字ごとに同じ数字が反復表示されるケースではその文字は結局置換されないので同じ形の数字が並ぶというプログラムの穴は……まぁ仕方が無いにしても、OpentypeFeatureのプログラムの性質から、Featureが改行するたびにリセットされてしまうので次の行の頭の文字は必ず同じクラスの文字から開始されるという事になるので、そこはちょっと格好が悪い。行頭に同じ数字が並ぶ場合やThis is改行The云々とした場合の両方のTは、文字の形が必ず同じになってしまって些か残念なことになってしまうからだ。そこでそこをもう少し改良する場合次のように、subの代わりにreversesub、まぁこれはrsubという短縮形がつかえるのだけれど、それを使って逆置換ルールで適応する。プログラムはこうなる。
rsub @number' @num_cv02 @num_cv01 @number by @num_cv03;
rsub @number' @num_cv01 @number by @num_cv02;
rsub @number' @number by @num_cv01;
当然これも単純なサイクル置換ではあるのだけれど文字列の長さに応じて、一文字目のクラスが順番に置き換わるから、行頭問題はある程度回避できる……ただ、文字の長さが単語ごとにランダムに変わる普通のテキスト列ならこのやりかたで自動的に行頭TheのTと、ThisのTの字形が変わるので、この方法でも最初のモノよりは大分マシには見えるかもしれないけれど、数字列っていうのは大抵文字数が揃って並んでいたりすることが多いというわけなので、文字数をランダムトリガーに使うと、結局結果が変わらないのでさらにもう少し工夫が必要になってくる。opentypecookbookでは文字全体のクラスを出鱈目に2つに分けこれをトリガーとして、そこから先行するグリフの状態に合わせてバックトラックで置換を実行することでテキスト列になんとか予測不可能な組み合わせを捻り出す……というアイデアが提案されている。この方法だとある程度の量のテキスト列があれば、わりとすんなり上手くいろいろな人を騙せそうではあるのだけれども、そのテクニックでも結局は、まったく同じ文字列が並ぶ場合はまったく同じに置換されるので、今回のフォントのように数字の10種類の並びだけしかなくてはランダム感は乏しくなり、そこはちょっとモヤモヤするところではある。というわけで、これらの置換モデルをいくら複雑に組み合わせても数学的なトートロジーが発動して最終的にはある一定の循環に収束し、結局何をやっても元にもどってしまうのではないかと頭の悪い俺なんかは思ったりもするので、充分に長いランダム配列を予め用意しておいてそれを呼び出すだけという単純な力業のほうが案外簡単に上手くいくような気もするのだけれど……まぁ俺みたいな馬鹿がうだうだ言うより、頭の良い人なら、もっとずっとちゃんと賢い方法を簡単に思いつくとは思うのだけど……。
で、じゃあ、まぁ、そういうことなので、キチンとしようと思ったらそこのところは最終的にはユーザー側でいちいち手作業でそれをやるしか方法はないだろうとは思ったりもしているのだけれど、そういうことにしたとすると現状今度はこのフォントでは選べるメニューが4種類しか無いので、バリエーションの幅が狭すぎてどうにも……と、いうわけで、もう少し居酒屋並みにレシピのメニューのほうを増やしてやるかということで、やってみたのがバリアブルフォント化。
今回作った4つのスタイルを極値にして平面空間の四隅にマッピング。つまり2軸のバリアブルフォントを作成することにした。本来こんなふうに泥縄で物事を始めると、マスター同士を綺麗に接続出来るかどうかの調整がかなり面倒なことになり作業の途中で頓挫することになるのだが、今回に限っては、変態技術者の魔法の言葉「こんなこともあろうかと」が発動する。要ははじめのデルタフィルターのみで異体字を作るという作業工程が幸いして、これをそのまま各レイヤーにコピーするだけで、簡単に4つの異体字がそのままエラーなしでバリアブルフォントのマスターに早変わりする……というわけ。
まぁ、バリアブルフォントについては、以前も色々やっているので、簡単な解説を文末にして、ここでは説明は省くけど、これでバリアブルフォントが中間のデータを無数に作るのでデルタの積み上げで手書き文字のバリエーションを無数に作ることが簡単に可能になる。本当は言うほど無数にもならないけど、まぁそれでも、上で作った異体字をランダムに表示させるプログラムなんかも、替わりにバリアブルフォントのバリエーションからグリフをランダムに選択するプログラム……というものをフォントの側に用意できれば、グリフに複数のCharacter Variantをそもそも作る必要は無いから、Character Variantを作る云々からここまでの作業は大部分が要らないと言えば要らないのだけれど、ただ、現実のところでは、「テキスト打ったときに異体字をランダムに表示させるプログラム」を「テキスト打ったときにバリアブルフォントの軸位置をランダムに変更するプログラム」に置き換えようとすると……つまりバリアブルフォントで、ある特定の軸位置に存在するグリフに対してFeatureの記述に応じて特定のインスタンスから軸位置が異なる別のインスタンス、あるいは別のマスターへジャンプする……というようなプログラムを仮にフォントの機能に組み込め……ないんだけど、それができたとしても、システムのほうがそれにちゃんと応えられるかということを考えると、そういう処理は相互作用が複雑になりすぎて、正直になにが起きるのかということが……まぁぶっちゃけどういう挙動になるかということの予測がまったく付けづらいので……そういうケースでアプリケーションがどう反応すればいいのかが本当は正しいのかと言うことすらもよくわからないということになる。
これは、仮にインスタンスの200と300で別のGPOSを持つバリアブルフォントのグリフabcに対して何かの機能を指示して、aの軸位置を200、bを300、cをその間の値253に変更しなさいという命令が可能になるという具体的なケースを想定しても、グリフのコンテキストルールではこの場合、多分aとbとのグリフ間で200と300の両方のルールがバックグラウンドで混在することになるからどっちを優先すべきかが本当なのかわからないうえ、これにcという中間の値のパラメータを処理するルールが追加されると……いや、まぁどうなるかわからないことを多分で言っても、返礼品をデータにすればコストもかからない、賢いヤツもいるなぁと思っていたら「ふるさと納税の返礼品がデジタルフォントを物品提供」という話を聞かされたときと同じくらいには反応に困ることになるから、まぁ、こういう話もあれなんだけど、ともかく色々あってシステムを実装する側だって多分そんなことは想定してもいないだろうから、そんなときにどうすればいいのかもよくわからないはずだ。Featureの記述に応じて特定のインスタンス、あるいはマスターを呼び出して反応させるという作業は、地雷の解体並みに危険を伴う複雑な問題がある。そもそもの話でいえばバリアブルフォントに特定のインスタンスから始めて別の軸位置を次々に呼び出すなどという方法が可能かどうかもわからないから、ここもはなしはそこからしてもうアレなんだけど。
で、たしかFontLabの偉い人のAdam Twardochは5年前ぐらいのツイートでだけど、現在のバリアブルフォントモデルでは選択された各バリアブルインスタンスがそれぞれ新しいフォントを構成するような仕組みになっているということからFeatureがインスタンスの垣根を越えて相互作用することはできません……というふうなことを主張していたので……まぁ、その後意見が変わったかどうかは知らないからアレだけど、当時はTwardochもこう言っていたので、今でも多分無理なんじゃないかな……という感じ。
ただし、その当時でも外側からならJavaScriptやpythonとかでランダム化のプログラムを作ってそれを使ってCSSからそのフォントのプロパティを調整し、インスタンスの呼び出しや、または直接軸の値を変更したり、はたまたフォントのベースラインをグリフごとにランダムシフトしたり……というようなことは、やろうと思えば可能は可能だったので、Web上の表示だけのことに限定すれば、概ねそのやりかたで問題は解決するから、フォントに怪しげなプログラムをわざわざ挿入するという必要性は皆無で、そのための努力は微塵も必要無い……と、まぁ、そういうことなのだろうけど。
というわけで、グダグダと言い訳はじめてみたら一周回って元に戻るという循環サイクルになっているという酷い落ちなんだけど、まぁ……聞かなかったことにして頂きたい。この手の話は実のところ、ネットで上澄みを検索するだけで物事が何でもわかった気になるだけの目的のユーザー相手のニーズに特化すれば「Opentype機能でバリアブルフォントのプロパティを変更することはできません」のたった一行で済んでしまうので、そう書いたほうがよかったんだろうけどね……トホホ。
さて、まぁ、では気を取り直して……異体字の字形へのランダム置換のはなしはひとまずはそういうことにしておいて、更に、まだ追加で色々怪しげな工夫を建て付て、手書き風をより手書きに近づける試みを続けよう。
手書き文字や、または手書き風のフォントを使用してデザインする場合、右肩上がりにbaseLineを傾けると収まりがよくなるというケースがあり、まぁこれは一般的に筆記体の文字が右に傾斜していることが多いのと、経験的に字を書いているうちに文章がなんかだんだん右肩上がりになっていくことがあるというケースが存在するということを知っているという、そのことを無意識が脳内をこねくり回す影響で感覚が騙されているようなこともあるのだけれど……そういうことをデザインでバランスさせようとすると、勢いベースラインを傾けたほうがそれっぽくみえるという理由になる。まぁ、理屈はどうでもいいけど、実作業としては文字のbaseLineの角度を簡単に斜めにできるillustratorのようなレイアウト系ソフトと違ってワープロソフトでそれをするのは些か面倒なので、OpentypeのFeatureにも対応したワープロソフトがあれば、一発で処理が可能になるようなFeatureの記述を追加することも可能だろう……と言うことで、この方法では、以前にも説明したGPOS制御のお出まし。position target valueRecord;というアレで、今回は筆記体のポジショニング処理……まぁ、おもにアラビア語などで必要とされるので、その処理のため利用されるのだが、そのためのルックアップを使用している。
pos cursive [＠グリフ] <anchor 0 0><anchor 字幅 アゲ幅>;
という感じ。細かい事を言うとOpentypeFeatureのGPOS LookupType 3の筆記体アタッチメントということになるのだが、仕組みは単純でcursiveに続けてグリフ名とアタッチメントの入口と出口の座標を記入する。字幅の揃っているもの同士をクラス配列にぶち込んでおけば、その分の数だけのプログラム行でOK。これで文章を打つ度にテキストが右肩上がりになっていくという文字をキチンと水平に並べられない非常に迷惑なフォントが完成する。ただしこの機能がフォントに追加されていると利点がある場合もある。これも、検討中のしょうもない自作フォントの例で申し訳ないのだが、たとえば下の図のような場合だ。
一番上は通常の状態で、これだとなんというかホリゾンタルラインが揃ってしまっていてフォントとしてはこれでもアリなのかも知れないけどパンク感が足らない。なので真ん中はレイアウトソフトでそれを単純にbaseLineごと傾けたもの。これだけでも多少はマシな感じにみえるかもしれないけど当然ホリゾンタルラインも一緒に傾いてしまって傾いたそのラインが揃ったままなのはいまいちだ。そこでOpentypeFeatureでbaseLineを1文字づつシフトしていったのが一番下になる。ホリゾンタルラインは水平を保ったままbaseLineが尻上がりに上昇し、雰囲気はこれで一気にパンクになる……え？ 意味がよくわからない？ うん、まぁ、こういうのは揃うところと揃わないところのバランスの問題なんだけど、パンクなんだからそういうところはなるべくガタガタしていたほうがいいじゃない？ だけどあんまりガタガタしていると勢いがなくなるので、全体のベクトルとしては右上がりに……ってまぁ、そんなことはどうでもいいのだけれど、ともかくそういうわけなので、こういうこともあるからスクリプトなフォントは傾けて使ったほうが格好良く見えるようになるかというと、概ねそういう傾向がないわけでもないのだけれど、そう単純にいかないということもあるんだよねというおはなし。またフォントのクリエイターの立場からすると人の作ったフォントを適当な角度で傾けて台無しにしやがって、せめてやるならこの角度にしやがれこのポンコツデザイナーどもめ！ っていうなんかよくわからない矜持みたいなものが発揮されたりする場合は、予めそういうプリセットをフォントに仕込んでおくことができるということも大きい。斜めにされたり，矩形を変えられたりするのを何から何まで極端に嫌がる人も中にはいるからね。 え？ 俺？ 俺はまぁ、別にそんなこと考えちゃいないのだけれど……。
さて、まぁ、雑談はともかく、ここからさらに、工夫すると先程のランダム化のテクニックを合体して、出力時にbaseLineを常にガタガタにしてしまうという嫌がらせ……じゃなかった、そういうテクニックでFeatureを記述する方法もある。まぁ、方法はなんでもいいのだけれど、具体的に一例を挙げると、以下のやり方がある。
まず、ランダム化につかうトリガーが必要になるので、一旦文字全体をいくつかのグループにわけてこれをトリガーにする。このときに、全体をどう分けるかである程度性格が決まってしまうのだが、まぁ、そこらへんはともかく、今は単純に仮に全体を2つに割って片方を＠Trigger1、もう一方を＠Trigger2として、＠Trigger1と＠Trigger2を合わせて全てのグリフという意味で＠Allというクラスも作成しておくと、後は簡単で、
lookup Yaxis1 {
pos ＠Trigger1 @All' <0 Δ1 0 0>;
} Yaxis1;
と、すれば＠Trigger1に指定したグリフに続くキャラクターのグリフのベースラインがデルタ1だけ移動する。ただ、このままだと結果がΔ1で総当たりしているだけなので、ガタガタの度合いは1種類だけだ。そこで次にこのlookupよりも前に、lookup……ここでは仮にYaxis2としているけどそれを追加して、
lookup Yaxis2 {
pos ＠Trigger2 @All @All' <0 Δ2 0 0>;
} Yaxis2;
lookup Yaxis1 {
pos ＠Trigger1 @All' <0 Δ1 0 0>;
} Yaxis1;
とする。このときトリガーも入れ替えておこう。これで＠Trigger1ではないグリフに続く次の次のキャラクターのグリフをデルタ2だけ移動した後に＠Trigger1の次のキャラクターのグリフをデルタ1だけ移動するということになる。Δ1とΔ2のサイズを変えておけばこれでガタガタ度合いは4段階ほどいける。まぁ、あとはこの組み合わせをどんどんバックトラックしていけばいいので、さらにこの2つのlookupの前にpos ＠Trigger1 @All @All @All' <0 Δ3 0 0>;、その前にpos ＠Trigger2 @All @All @All @All' <0 Δ4 0 0>;、さらにその前にpos ＠Trigger1 @All @All @All @All @All' <0 Δ5 0 0>;、それからpos ＠TriggerX @All @All ……@All @All @All' <0 ΔY 0 0>;とlookupを気の済むまで追加していけばガタガタがもそれに合わせてどんどんと増えていく。この方法は、多分、お気づきのように先程話題に載せたopentypecookbookから引用しているので、もうちょとまともでちゃんとした説明が知りたいのならそちらを参照してほしいのだけれど、キャラクターを引き金にしてグリフがガタガタするので打ち込んだ文字によって見た目が変わるという算段だ。トリガーとデルタにいろいろと気を配れば、それなりに見た目は悪くない……というか、ベースラインがガタガタになって見た目は悪くなるのだけれど、こうやって一手間加えると、このやり方なら異体字のない普通の手書き風フォントでも雑で微妙にラインの揃わない本格的な手書き風フォントにお手軽に早変わりする……かもしれない……というわけ。で、作成したいくつかのパターンをFeatureのStylistic Setにリストアップしておくと、posでの位置移動がリセットされずに累積するため、途中でやらかしたバリアブル化と相俟って選択したスタイルの組み合わせによっては結果はプログラムを書いた本人ですら上手くいっているのか、どこかでミスをしてバグっているんじゃないかということすらもわからない程度には予測不能な事にはなる……まぁ、それが良い感じなのか駄目な感じなのかは別だけど……ともかくそんなふうには出来るので、まぁ、ここまでの手順ならわりと簡単でしょ？
さらには、FontworksのAI JIMOJIみたいに、自動的に文字を生成するツールを利用して複数回出力したフォントグリフを異体字として一つのパッケージの中に組み込んで、今回のおはなしのようにOpentypeFeatureでランダム風な組み合わせを引き摺り出したり、baseLineをガタガタにするだけで、AIガチャのハズレを引き当てたなんかいまいちの手書き風フォントの山を、いとも簡単にかなり本格的にまともでないイカレた手書き風フォントにバージョンアップできるということもあるのだけれど、まぁ、無料で提供されている他人のサービスに乗っかってそこまでやるのも野暮なので気が引けるから、そのはなしはしないので、まぁ、お好きにどうぞって感じなのだけど。ただ、こんなふうにはイージーにいろいろと出来るとは思うので、このあたり作業するだけなら簡単そうでしょ？
まぁ、ともかく話を戻すと、ただ残念なことに前にも言ったけど、現在のイラレの日本語版ではGPOSの一部のルックアップに反応しないので、このあたりの仕込みが役に立たない。まぁ、最新のインデザインならなんとかなるのだが、ノンデザイン系のツールだと、そもそもFeature自体に反応しないというものもあるので、問題は山積みだ。また、そのことは一旦忘れたとしても、手書きのアログリフさをシミュレーションしようとするにはカーニングや、文字の大きさや太さの乱雑性とか、まぁいろいろと他にもやることはいっぱいあって、俺の気が付いていないことも大量にあるとは思うけど、どれもこれもこの後、手作業ですぐ簡単に処理できるという話の域を超えてしまい、それこそ天才デザイナーAIちゃんのお仕事になると思っているのと……いいかげん駄文もだいぶ長くなってきたので、今回はここまで。
というわけで、今回のサンプル。いつも通り余計なコトしかしていないうえにまともにデバッグしていないのでドコで何が起きるかはわからない。ということで、お約束として、いつも通りの自己責任で。
Handwritten Numbers Regular OpenType/CFF variable
24 characters. It has 3 axes and 50 named instances.
と、こういう感じなんだけど、さっきも言ったけど手書き風フォントは手書き風フォントでそれなりにジャンルが確立しているように思うので、実際こんなことしてるけど個人的には別に手書き風フォントを無理に手書きに近づける必要も無いとは思っているんだよ。それよりは、このあたりの仕組みはもっと別のモノに応用できないかと悪巧みはしているんだけど……まぁ、それは別の話として、それと、本当にどうしても手書きが必要ならばちゃんと手で書けば良いんだよ……って、ホント、こういうと身も蓋もないけど。
ただ、誤解されないようには念を押して置くけど、こういう手書き風フォントというものは、作業の簡略化やデザインのワンポイントで使用される以外にも、ディスレクシアに効いたり、ファンクラブへのノベルティになったり、用途に応じてまだまだケースバイケースで必要とされる場所はいっぱいあるし、新たな用途が開発されることもあるから、どこかのお偉い先生気取りで手書き風フォントのことを駄目だと言ったり手書き風フォントが増えていることに不愉快と言って難癖をつける気はホントに一粍も無いんだよ。自分でも作ってるし……ただ、本格中華麵を食べようと思ってお店に来たのに回転テーブルの真ん中にカップヌードルを置かれたら、その場合はちょっとイラッとするかもしれないけど……まぁ、それもコレもこういうことは、時と場合と場所とトンマナという実にあたりまえのはなしなんだけどね……但し、こんな頓馬なおはなしにおいてさえも、カップヌードル自体には何の問題も落ち度もないということくらいはわかるよね？
いつもの用語解説
GPOS コレに関してはこちらでも書いているのでそれを参照。
Opentype Feature まぁ、これに関してもちょっと前にも書いているので、そちらを参照。
アログリフ タイポグラフィックにおける書記素の異なる形式、シノグリフ、オルタネイト、または異体字。それぞれニュアンスが若干異なるのだけれど、どれも「意味は同じだけど形態が異なるグリフのこと」程度の理解でまぁ、概ね問題は無い。これでなんとなく意味はわかるよね？ 厳密なことを言い始めるとＡとａはアログリフだけどシノグリフではないとか、その説明は間違っているとか、いろいろそういう面倒なことを言い出す人もいるから、まぁそこのところはともかくとして、それで、手書きの文字は基本的に当然、全てがアログリフなので、まぁここでの話はよく考えてみたら何かを言ってるようで実は何も言っていないのと同義ではある。
異体字 字の意味が同じで字の形の違う字のこと……なのだが、細かく突っこんでいくと意味やら定義やら見解やらがいろいろあるので、面倒くさい。はなしをシステム的な話題に限定してもUnicode上でコードポイントが同一でサフィックスが異なるグリフをそうみなす以外にも、コードポイントが異なるが異体字とみなされシステム上でもそういうふうに扱うことが推奨されているグリフ、異体字なのか異体字でないのか見解が定まらないモノ、ケースによって異体字扱いされたりされなかったりするもの……と、まぁいいだすとキリが無いので、専門家でも突っこんでいくと理解があやふやだったりするから、素人の理解があやふやだからといって、鬼の首を討ち取ったが如くの勢いで下卑た言い方で人のことを責め立てるのは……ホントよくないと思うよ。
インスタンス バリアブルフォントのマスターからAxisのパラメータをもとに補間されたデータから構築されたプリセット。マスターがウルトラライトとウルトラボールドのみというバリアブルフォントからボールドやミディアムといったサイズを呼び出すときにいちいちパラメータの軸を押したり引いたりしなくて済むようにフォントに予め定義されている。フォントの種類によってはAppleの時刻表示専用フォントのように、ここの定義がやけに細かかったり、逆に、極値プラスと極値マイナス、以上。みたいな相当にぶっきらぼうなものがあったりだとか……まぁ、そういうことはいろいろとある。
キャラクター 書記体系の基本単位で、文字通りに文字のこと。ふつうは一つのフォントのキャラクターには1つのグリフがあるだけなのだが、今回の話はまったくそういうことにはなっていないというところで、そろそろ、このおはなしの内容がいかにイレギュラー且つアホなことをしているのかということが、おわかりいただけたかとは思うのだけれど、そこはともかく、まぁそういうわけでキャラクターとグリフはしばしば同じ意味に使われ、通常の場合それで意思疎通に問題は無いので、細かい事を気にする必要は無い。
グリフ 文字を構成する書記素の形。日本語で字体のこと……という説明がされることもあって、まぁそれで概ね間違いではないのだろうけれど、字体では概念として、構成する書記素全体の集合の外側に被せる集合に付ける名前として使われてしまう可能性があるのだが、データとしてのグリフの持つ意味は書記素単品以上でも以下でも無いので、グリフと書かれている場所を字体に置換してしまうと意味のわからないちんぷんかんな文章が出来上がる。つまり、字体とグリフを同じと言ってしまうのは、しばしば間違った説明になってしまうということもある。
サフィックス 拡張子。Opentypefontでフォントファイルの中にUnicodeでおなじコード位置を共有する別のグリフを包摂するため、内側ではUnicodeとは別にグリフインデックスの値……つまりGIDが別々に割り当てられ個別のグリフとして管理される。Opentypeではこれをcmapテーブルを介して<map code="XXXX" name="glyphXXXXXX"/>のようにしてUnicodeのコードポイントに接続しているのだが、GIDだけで管理されると、どのグリフがどのキャラクターなのかということが人間様には直ぐには理解が及ばなくなるので、もとのグリフの名前の下に拡張子を追加するという表記で同一性障碍を克服するという役割を果たすために存在する。拡張子をどう付けるかというのはある程度のルールみたいなものはあるのだが、フォントエディタで管理される場合、縛りはそんなに厳しくはない。
デルタ 定義の話からはじめるといろいろややこしいことになるのだが、ここでは値の微少な差分を表す要素的な意味で使用している。バリアブルフォントを構成するもっともプリミティブで重要な概念のひとつ。
ノード 点のこと、フォントデータは点と点を結んでストローク……まぁつまり輪廓線を作り、その線で囲んで内側をつぶして麺……じゃなかった面にする。まぁ、このあたりは常識的なところなので言うに及ばず言わずもがななのだけれども、まぁそれはともかく、そういうわけでデータとしてはこのノードは最低限XとYの座標データ2つ、最大で曲線のハンドルの位置の座標データと併せて6つの数値から構成され、ハンドルがある場合はこのノードは極値に置きハンドルを水平もしくは垂直にポイントするということが推奨されてはいたのだが……ただまぁ、その辺りは古いType1フォーマットに由来することも大きいので、実を言うと教科書に念押しで書かれるほどマストというほどのことでもない。ただし、そうなっている理由はあるので、ベクトルをどう描画すると美しいラインが描けるのかということと、そのラインをA/Dコンバートしたときに不都合無くデジタれるのかというところの部分のことに関してはいろいろアレな話はある。なので、まぁそのあたりについては気が向いたらまたそのうち。
バリアブルフォント 検索すればいろいろ出てくるから、ちゃんとしたことはそっちを見て貰ったほうがいいのだけれど、簡単に説明すれば一つのフォントファイルの中に複数のスタイルをシームレスに包摂する仕組み。フォントはファイル内に相互に関連付けられた複数のグリフデータ集合を持ち……って、まぁ、マスターって言うんだけど、キャラクターはそのファイル内の複数の集合をパラメータのベクトルでスカラーしたマトリックスから……ってまた適当なこと言ってるな、要は複数のマスターのデータを使って変数で補間すれば中間値が計算できるのでその計算された答のデータを使ってグリフの形が再構築されて出力されるという仕組み。そのためスタイルの数だけフォントファイルが必要になる従来のやりかたと比較して圧倒的にサイズを圧縮できることと、動的な変化に対応できること、それにより従来のフォントでは不可能だった微妙に中途半端な中間の値を柔軟に扱える……などという部分が特徴と宣伝文句にはなるのだが、そのため出力されたフォントの形はほとんど同じに見えるとは言え、従来のデジタルフォントと比較するとデータの構築ルールにもそれなりに異同と限界が存在するので、実を言うとまったく同じにできるというわけでもない。バリエーションが必要無ければバリアブルでないフォントのほうが遥かに良い場合もある……のだが、まぁ、ただ最近は先にバリアブルフォントを作ってその出力から複数のスタイルで構築されるバリアブルでないフォントを作成するというようなこともしているようだから、そうでもなかったりもするのだろうけど。
パワーストローク ノードのところでも言ったけど、デジタルフォントのデータはパスで閉じられた空間を塗りつぶすことによって文字を構成するという、レタリングチックな仕組みによって出来上がっているので、ストロークが一筆で閉塞している必要があるのだが、FontLabでは書いたストロークをオフセットして文字をデザインするという骨骼ベースでの作業をサポートしているので、パスを開いたままにしていてもエラーにはならないようにはなっている。ただし、輪廓にそのようなストロークが存在する場合通常のストロークだと、始点と終点を最短距離で接続し、内部を強制的に閉じようとする力が働きパスを骨骼として認識しないので、輪郭線にpowerStrokeというフィルターをかけてstrokeにパスをオフセットした仮想の輪廓データを強制的に追加する。輪廓データはパスが変更される度に更新され、フォントのデータとしてはFlatten layerなどによって認識されるまでは決定しないというシュレーディンガーズキャットな状態になっている。まぁ最終的には筺は開ける必要があるんだけど……。
ベースライン 活字を揃えて並べるときの基準線。デジタルフォントの場合この位置がY軸のゼロになる。このラインは一般的に欧文フォントでは大文字の下を通過するのだが、日本語のフォントではそうなっていないので文字をbaseLineに揃えても文字の下では揃わないということになる。もっとも、日本語の活字は本来中央に揃えないといけないので無理矢理文字の下を揃えるとこんどは上がガタガタになってみっともないというケースもある。というわけで、日本語の文字のbaseLineというものを考えた場合は本来そのラインは文字の中央を通っていないといけないのだが、いろいろと複雑な事情があって、デジタルフォントではそういう設定にはなっていない。なお、文字を縦組にした場合のbaseLineは文字の中央を通過することになっていて……まぁここにもいろいろとオトナの事情がある。
ホリゾンタルライン 水平線。デザインなんでもそうだけど、水平垂直は揃うところがきちんと揃っていないと、人間の脳にはそのあたりの違和感がストレスに感じてしまうことがあるらしく、いろいろな意味で危険が危ないので注意は必要だ。一般的に人間の脳では垂直より水平への意識のほうがより重要で、逆に言えば水平が認識されればそこに多少傾いているモノがあってもあとは勝手に脳が自動で補正してくれるというようなことになっている。ただ個別のケースによってはいろいろあって、もちろん個人差の影響もいろいろとあるんだけど、このはなしも話すと長くなるので……またそのうち。
ルックアップ 事前に設定された条件から結果を出力するための対応関係をまとめた手続き、またはそれらの関係を纏めたテーブル。まぁプログラムのサブルーチンみたいなものだけど手続きを簡素化するためのプログラム上のテクニックは色々ある。OpenTypeではGPOSとGSUBにもそれぞれ複数のタイプがあり、FeatureのLoolupでは、一つのLookupの中身はおなじタイプのルックアップでアレしている必要がある。当然それらがどのタイプのルックアップを利用するかは宣言する必要があるのでLookupのブレース括弧の中の頭に lookupflag ナントカ; という行が本当は必要になるのだがGlyphsやFontLabのようなフォントエディターではそのあたりは出力時に自動的に設置されるので、ゴリゴリにアレをアレするというわけで無ければ、あまりそれらのタイプとの関係がどうなっているかということを気にする必要はない。なので、大抵の解説書ではこのあたりのはなしは説明を始めると面倒なことも多いせいか、ほとんどの場合端折られてしまっている。まぁ、もっと細かい事をいえば、フォントエディターを使えばこのあたりのことも自動的に設置は済んでしまうけど、本当はFeature自体もlanguageごとに個別に設置されるので、言語設定ごとに同じモノをコピーして内挿しているわけだから、ここをhackして個別の言語ごとにFeatureの振る舞いの変わるフォントみたいなものも作ることは出来るんだけど……そんなことをして誰得なのかという問題はあるのと、あと、その話も長くなるのでまたそのうち。
ワタナベさん 洒落を解説するのは忍びないのだが、今回の内容に関わることなので一言だけ。日本だけで100万人以上が生息すると言われているワタナベさんの漢字に数多くの異体字のバリエーションがあるということはよく知られているのだが、実際にどのくらいの数が必要なのかということについては21世紀においてすらよくわかっていなかった。一昔前は三十数種類といわれていて、これでも十分多いんだけど、調査が進むたびに数が増え、現在ではナベだけで58種類という説も有力になってきている。これは主に戸籍への記載ミスなどが大きな原因ということがいわれているのだが、日本に一番多い名前のベストテンにも入らないようなサイトウさんのサイですら遥か平安にまで時代を溯って記録をあさると確認されるものだけでも85種類ものサイがあるということもいわれていて、大昔にOpentypeのCharacter Variantが99もあると聞いたときはオーバースペックだなぁと思ってはいたのだけれど、いまでは逆に足らなすぎるのでは無いかと若干危惧している。