colon:semicolon;comma,period.
コロン、セミコロン、カンマ、ピリオドはまぁ、欧文用の記号で日本語では点、丸。（括弧）と一緒に括って約物という種類に分類される所謂パンクチュエーションマークというもののお仲間というやつになるんだけど、欧文専用記号というわけでもないので、この意味や形が和文のテキストでも利用されていないわけではないというのはご承知の通り。
まぁ、ただ、利用されるといっても約物の正書法は現代でもまだフラフラしている部分が多いのと、こちらもご承知とは思いますが、コロンやセミコロンは和文と英文では使われ方も意味も少し異なっていて、欧文の方が和文よりはその利用目的も使用方法も若干厳格ではあるのだけれど、ただ、その欧文にしたって正書法が出来上がってくるのは活版印刷の普及に伴って緩やかにルールが決まっていったという事情もあって、確定したと言えるのは長く見積もっても100年に達するかどうか……まぁ、ここは歴史と伝統をどのあたりをベースに語るかによってもいろいろとあるんだけど、流石にアリストパネスだアルダスだのと言い始めると、地域を無理矢理実効支配し勝手に代表者面した揚げ句、国内のみならず隣国の民間人までをも無差別に虐殺陵辱拉致監禁するような極悪非道の暴力組織の所業を糾弾するだけの簡単な話に、ムハンマドやらイギリスの三枚舌外交を持ち出してワケのわからない説明をした揚げ句、罪状をうやむやにしようとする阿呆な連中並みの話にはなるので、というか、もうすでに何言ってんだコイツみたいなことになってはいるけど、まぁ、そういうことにはならないように、今回は現在一般的に利用されているルールに沿ってのおはなし。フォントデザイン上の注意点……みたいな感じ。まぁ、ホントは、ちゃんとした話はこちらにあるのでそちらを見てもらった方がいいのだが……。
さて、コロンとセミコロはともかく、カンマ、ピリは和文ではほぼ点丸に相当しているので、それぞれ句点、読点という扱いで和文のテキストの点丸と役割を交代しても問題無く利用できるということにはなっている。まぁ具体的には以下のような具合になる．過去には公文書でも確か横書きに限ってと言う話だったはずだけど，点丸の替わりにカンマと丸で代用してもOKということにはなっていた．欧文のセミコロンに対応する“読点と句点の中間ぐらいの役割をするような約物”というものが日本語にはないので，まぁそのあたりは必要があれば必要に応じていろいろするようなことにはなるのだけれど．
というか，横書きで公文書を作成する習慣の少なかった時代には，それこそケースによってまちまちだけれども，むしろ積極的にそうするように推奨されていたりしたことさえあった．それからしばらくすると，ワードをプロセッシングする機械なんかの普及によって今度は縦組の公文書そのものがレッドデータブック逝きということになるんだけど…って，いや，まぁそこら辺はいいとして，まぁそういう時代になったことでもあるので，今更横書きだから点はカンマにしろなどといいだすと〝はいはい，おじいちゃん…お薬の時間はまだでちゅよ〟などと言われかねないので，そういう主張が正しいみたいなことは言わないけれど，ただ昭和の時代では，左綴じの学術誌から，ちょっとデザインしました風の熱った横組の雑紙まで，点の替わりにカンマを打ってある方がちょっとわかってる風でセンスがいいというくらいの感じまであった．まぁ，今でもそういう仕様の書籍はあるんだけど，こういう主義も主張も派閥がマイノリティになっていることもあって，逆にいまでは旧弊丸出しで，なんなら誤植を疑われる…くらいに現代人には見えるのかもは知れないんだけど．
さて、もう煩わしいので元に戻すと、まぁ、そういうわけで、この場合読点を丸にするのかピリオドにするのかとかでも派閥があって、まぁたしかに句点をカンマにしたら読点がピリオドでないのはおかしいという派閥と、当時の印刷精度の問題でピリオドでは潰れた読点なんだか汚れなんだか区別が付きづらいからキチンと丸いほうがいいとか、どっちの言い分もわからないではないんだけれど、ゴチャゴチャ決まらないんだったら最初から点丸で良いだろうとか俺なんかは思うのだけれど、でも、まぁここは下っ端が口出す話でもないからアレだったりして、まぁそれはともかく、それにアレだ……なかには句点は点だけど、読点はピリオドなどという、なんだかよくわからない謎ルールが発揮されてしまっていたりしているものもあったりとかして、このあたりは、まぁ何というか……今思うとホントどうでもいい。
というか、まぁ、こういうものもホントのことを言うと一つの文章内でルールが統一されていれば、まったくもって問題は無いのだけれど、そういう問題ではないというご主張のお方はいらっしゃるので、関係者が増えていく度に意見が違ってホント面倒くさいことになるんだよね……まぁ、そういうわけで、面倒な話し合いの嫌いな現代人はこの文章のように、横書きでも点丸がスタンダードになるという選択をしているという……え？ そもそも、そんなことすら気にしていない？ まぁ、そうかもね。最近ではネット上のやりとりでは文末にピリオドを打つと怒っているように見えるから使わない……などということも言われるようになっているという……まぁそういう時代になったのだという話も聞くし、将来的にはこういう約物の役割なんかも、使われ方や媒体に合わせてどんどんと変わっていくのかも知れないんだよね。
さてと、戯れ言はここまでにして、ここから本題。これらは只の点丸で、フォントのデザイン上では一番プリミティブな部分に当たるのだけれど、この部分の出来が悪いとフォント全体の性格を酷く捻じ曲げてしまうことにもなるので、多少なりとも注意は必要だ。こういう点丸を欧文ではどうデザインするのかというと、慣習？ 伝統？ まぁ、言い方はなんでもいいけど、そういった若干緩い決まり事のようなものはある。まぁ毎回言うけど、こうしろとか、これが正しいとかいうおはなしではないからね。こういう話を真に受けて奇妙な棒を振り回し、周りに迷惑を掛けるような駄目なオトナにだけはならないようにして欲しいものです。イヤ、ホント。
それで、一般的に欧文のピリオドは図形の下端がベースラインの位置に置かれ、点の形はｉのドットと同じ形になっている。というか、ｉのドットがピリオドと同じ形になるんだけど、そのあたりの鶏卵問題はともかく、そういうことなので、まぁつまりｉのドットが丸だったら丸、四角だったら四角くなる……え？ 三角やハート型？ まぁ，同じでも良いんだろうけど機能的にはいろいろと問題はあるよなぁ……まぁ、その辺りはどうでもいいので話を戻すと、このドットをベースにカンマを作って、その素材をもとにコロンとセミコロンに拡張する。コロンとセミコロンはフォントのｘheight……つまり小文字の高さに揃えるように調整するのだが、ただ、まぁ、後で説明するつもりではいるけどコロンはそれだと問題になる場合もある。ただ大抵のフォントではその部分のことに関しては存在していないことにはなっているから、とりあえず無いことにして話を進めると……ってまた、説明が煩わしくなっているのでここから先は図にするけどまぁざっとこんな感じ。
まぁ、だいたいは見ればわかると思うけど、ａってなっているｉのドットの形を基準にグリフのステムと同じくらいに見えるような幅のドットで、ｂの幅のピリオドを作って、下端をベースラインに揃えたら、ｄの高さをピリオドの高さのだいたい2倍ぐらいになるような位置までカンマのテールを下ろしてやり、そのピリオドとカンマでコロンとセミコロンを作成する。偶にテールの下端がdescenderに接しているモノも見かけるけど、そこを無理する必要は無い。コロンの上端はx-heightの高さと同じか、それよりは低い位置でバランスさせるけど、バランスはだいたい小文字で作った単語の塊を鶏肉だと思って串刺ししたときの串が良い感じにコロンの真ん中を通過するぐらいをイメージする。コロンの上の点と下の点の隙間はピリオドの高さよりはなるべく広く見えるように……つまりは縦に並んだ2つの点がちゃんと分離して見えるように調整する。錯視対策が必要なら上のドット、つまりｃの部分をピリオドより少し小さめにするとか、まぁそういうふうなことをする必要はあるんだけど、その理屈は上下のドットの大きさが見た目で同じ大きさに見えるようにするためなので極端にサイズを変えたりしない……と、だいたいはそんな感じで完成させる。他に言っておくことは無かったかな？ まぁ、ともかく基本的にはひとつ決まれば機械的に色々なところのサイズが決定するということなので、言ってしまえば、まぁ簡単だね。
という感じなんだけど、ところが最近はもう、普通のフォントはファミリーを作るのが一般的には当たり前になってきているから、そういうことも勘案すると、なかなかそうはうまく計算通りにはいかないというか、現実世界はなかなかに……まぁ思った通りにはならないようには出来ている。ここも、図にしたので、見ればわかると思うけど、こんな感じ。同じ家族のウエイトの違うもの同士を横並びにするとこんな感じ。
荒い説明を加えると、上から二番目、Futura寄りのジオメトリックなサンセリフBill Corp Narrowのグリフのドットは丸なので当然ピリオドも丸で作成されている。逆に、一番下のHelveticaはｉやｊのドットが四角いドットでデザインされているのでピリオドも四角くなるんだけど、Helvetica Nowには、なんといろいろな異体字が付いていて、選択式で丸いドットも選べるようにはなっている。まぁ、その場合でもｉやｊやドットの必要な他のグリフもドットの丸いものが選択出来るようにはなっているので、普通はそっちも揃えるというのが正しい行いというものなのだろうが、どうせそこまでするのならそもそもHelveticaの必要があるのかどうかというのは……イヤ、何でも無いです……まぁ、ともかく、そういうことなので揃えないという選択も出来てしまう。こんな感じでHelvetica Nowはなんとも恐ろし……いや、失礼、素晴らしいフォントに進化している。
さて、カンマの上半分はピリオドのデザインと揃えても揃えなくても構わないのだけれど、大抵の場合はテールのデザインが、他のグリフのテールやターミナルの形に影響される。逆にいうとその辺りが揃っていないと、全体的に作ったフォントがチグハグな感じに見えてしまうという原因にもなるということなんだけれど、Mutableのようにフォックステイルとは揃っているようには見えなかったりBill Corp Narrowのように細いweightと太いweightでデザインを変えてしまうというようなことをするフォントもあるので、まぁこのあたりもバランス次第。ただ最近のフォントは概ね、weightの差でx-heightを弄る……みたいなことを何となく嫌がるようにはなっているので、ステムの幅が大きくなればそれに併せてドットのサイズも大きくなるけどx-heightが動かないからコロンの二つの点の間隔は太いフォントのほうが細いものより間隔が狭くなってしまう……のはまぁ当たり前なんだけど、Actaのようにコロンの上端からx-heightまである程度余裕を見積もっておけば、ここの高さでの微調整は効いてくるので、まぁ、そういう解決方法もある。
あとまた、日本人に対しての注意点としては、和文のフォントでのドットの扱いは一般的に他のキャラクターに比べると若干控えめなサイズでバランスさせるという感じなのだけれど、欧文のフォントを作るときは、和文のときのバランスで考えるときの何割か増しでピリオドを大きめに想像して作ってあげた方がいい。このあたりは和文の点丸が何故あの大きさなのかを想像するとなんとなくわかるとは思うんだけど、感覚的なことを説明するのは非常に厄介なので……まぁ、塩梅によるとだけは言っておく。こういう場合、ある程度の思い切りは肝心だ。
それで、さっき言いかけたけどコロンに関してはテキストの中で使用する場合と時刻の表示に使用する場合とでは位置を変えてあげる必要がある。つまり、本文中のコロンはｘheightに揃える必要があるけど、時刻表示や数学記号として使用する場合は数字のセンターに揃えるほうが望ましいという、そういうこともあるからなのだ。ケースによっては大文字だけでタイトリングするとき用に大文字の並びのセンターに揃うコロンを用意する場合もある。
ただまぁ、そうはいっても最近ではコンピュータが勝手に調整してくれるようにもなってはきているので、まぁあまり気にもしていない人もいるだろうし、いちいち気にするのも面倒くさいので端から無視を決め込んでいる人、コロンを真ん中に揃えるというカルチャーのなかにいない人、更にはまぁそもそも和文のフォントが欧文とは違ったルールで出来上がっているのでそこはあまり気にする必要がなかったりもするということがあったりなかったりもするということはある……のだけれども、オフィシャルなルールとしてはそこははずしては駄目なことにはなっていたりもするので、レイアウトをするときは、そのあたりの調整が必要になるという場合もある。まぁ最近はそんなこと気にしちゃいないという人のほうが多いんだけど、ただまぁこういうことが気になり出すと、いちいち目を皿のようにして手作業で修正して回る羽目になり、これを、また、いちいち手作業するのも非常に面倒なので、巷間にはそこそこバッドなチップスも出回っていたりはすることもある……のだけれども、AppleのOSでは休憩中の画面にドカンと時刻が表示されるというようなこともあるので、その時刻表示に利用されているSF Soft Numericという名前のバリアブルフォントでは、これをOpentypeFeatureで補完するような塩梅の仕様になっていたりはする。
というわけで、いつものコーナー。さて、まぁ、これも毎度おなじみなんだけれど、Opentypeのフォントには、テキストの特定の役割のためにインテリジェントな振る舞いを行えるよう……って、まぁ、この言い方だと大げさだけど、ようは定まった目的のためにフォントが機能するようにするための仕組みとしてOpentypeFeatureなるものが用意されている。今回もこれを悪用して、時刻表示にも対応出来るようにするためのフォントを作成する。
ただし単純に済まそうと思ったら、Web上の表示ではCSSでbaseline-shift プロパティを弄ればどうにでもなるので、ある意味わざわざフォントに面倒なプログラムを持ち込む必要もないんだけど、イラレやインデザインのようにベースラインシフトを割合で指定できないアプリなんかの場合だと、文字の級数が変わる度にシフトするサイズをいちいち計算し直さないといけないので、こういう機能が盛り込んであればある程度は役にはたつということになる……まぁ、端から気にしないのであればそこら辺はどうでもいいし、和文グリフのコロンなら始めからセンターにしか揃っていないので、それをする意味さえ無い。まぁ個人的にただやってみたかっただけという頭の悪そうな理由しか思いつかないのだけれど。ホント。
今回サンプルとして使用するのはこのフォント。某電気自動車メーカーのロゴにインスパイヤされてしまっているんだけど、まぁ何となくはわかるよね？ 実はいってるそばから自分の言ったことも守れない基本ルールに則っていない駄目な大人を体現するような作りのデザインのフォントにもなっていたりはするんだけれども、まぁ細かい事は気にしない。ともかく、今回はこれにOpentypeFeatureのプログラムをぶち込んで時刻表示に機能させるというスタンスだ。
それで、その肝心なコロンと数字はというと、現状のままだと下の図のような感じ。このままの状態で日付と時刻を表示すると、図のようにいろいろなところが残念なので、どういうふうに修正しようかというおはなしになる。
それで、単純に考えればコロンのグリフのポジショニングをセンター合わせに変えるだけなのでOpentypeFeatureでGPOSの位置を弄って、下の図に示すようにターゲットのポジショニングを調整するだけだから pos target valueRecord; という感じのプログラムでホントは大丈夫なはずなんだけど、下の図のようにベースラインまで弄ると、前にも説明したと思うけどアプリによってはこれがうまく働かなかったりすることもあるので、希望するシステムでうまく動作するかどうかの確認は必ず必要になる。あと、これは偶に忘れていて、間違いであたふたすることもあるという俺個人の問題なんだけど、グリフの左右に同じ幅のスペースを取りたいときには、xAdvanceのサイズをxPlacementの2倍にしないといけないんだよね。理由はまぁ図を見れば一目瞭然だから、ここはいちいち説明するまでもないとは思うけど……わかるよね？
まぁ、でも今回はbaseLineを変更するようなことまでしてポジショニングの変更を行うという必要は微塵もないので、GPOSを弄る方向で……とりあえず、調整してみる。実をいうと今回参考にしているSF Soft Numericなのだが、このフォントがpositionではなくて、わざわざ異体字を用意してまでGSUB……つまりsubstituteでグリフの切り替えを指定しているという理由がわからないから、本当のところはこのやり方で大丈夫なのかは……心配で、ちょっと恐いんだけど……まぁ、いいや、やった後で考えよう。
さて、コロンのポジショニングの変更が行われるためのトリガーが必要になるのだが、Opentypeでは
feature Trigger {
pos target valueRecord;
}Trigger;
みたいな感じに記述されるTriggerの名前が引鉄になってbrace括弧の中に記述されたインタープリターが発動するという仕組みになっている。まぁ、Triggerにあたるところの名前は基本的には何がどうこうと予めちゃんと決まっているので、ここの名前を間違えると機能が発動しなかったりはするんだけど、最近のフォント制作アプリではこのあたりの自動化はかなり進んでいて、あまり特殊な事を考えなくても大丈夫なようにはなっている。今回のように余計なことをしなければだいたいはポチッとすれば終了する。このあたりのはなしは……まぁ、俺がだらだらと話すようなことでもないから、気が向いたらまた今度。
さて、ともかくこういうわけで、ってどういうわけだかわからないだろうけど、そんな感じなのでトリガーの種類はそれほど多いというわけではないので、フォントに複雑なことをさせようとすると直ぐに暴発してしまう。ということで、今度は逆に余計なところで機能が爆発しないように暴発を防ぐ安全装置を組み込む必要がある。実際のところOpentypeFeatureのプログラムっていうのは、基本ほぼ暴発をどう防ぐか……みたいなことしかやっていないというところまである。まぁそこのはなしもともかく、そういうことでなるべくなら発火装置も安全装置も単純なほうがいいので、今回の場合は
@fig = [zero one two three four five six seven eight nine];
pos @fig colon' @fig <xPlacement yPlacement xAdvance yAdvance>；ざっとまぁこんな感じ。説明しなくてもわかるだろうけど一行目は＠で定義される配列にゼロからナインまでの数字のグリフをぶち込んでいる。で、2行目でターゲット……今回の場合はコロンのみなので、Glyph Nameのcolonを記述し、コロンが配列の中のグリフに挟まれた場合のみを発火条件とするという印にコロンにシングルクォートの撃鉄を立てておく。コロンのポジショニングは今回のケースならyPlacement以外は全部0で良いので、このフォントの場合はy軸を150ユニット分だけ上に移動すればコロンが数字のセンターに揃うという仕掛けで実際のlessとgreaterの中身は、<0 150 0 0> ということになる。これで爆弾は左右に数字が揃うまでは爆発しないという仕組。
さて、引鉄が一つだけならこれでお終いなんだけど、複数箇所に発火装置を仕込む場合は、複数のトリガーに同じ記述をコピーしてやる必要がある。今回のようなケースなら単純だから全然問題無いけど、複雑なプログラムをその都度修正するようなことをすると本当に面倒なことになるので、最初に設置しておくが吉。ということで、これが所謂ルックアップというものの正体で、トリガーとなるfeatureより前に
lookup Name {
rules;
} Name;
の形で定義しておけば、
feature Trigger1 {lookup Name; }Trigger1;
feature Trigger2 {lookup Name;}Trigger2;
feature Trigger3 {lookup Name;}Trigger3;
feature Trigger4 {lookup Name;}Trigger4;
というようにいくらでも手が抜けるという仕組みだ。まぁ、今回のようにポジショニングを弄っている場合は複数の箇所で爆弾が破裂すると、位置の移動が累積していって面倒なことにはなるんだけど……って、あ〜、そうか、そういうことで、SF Soft NumericはGSUBで定義しているわけか……なるほどなるほど、確かにインタープリタなブレースの中からはどこで爆弾が破裂しそうなのかは確認しようがないかも……まぁ、そこのところは確かに多少工夫がいるので……フラグを突っこむとか、順番変えるとかそういうことを少し考えないといけないけど……まぁいいや今回は成り行き任せで。
あと、これは言うまでも無いとは思うけど、OpentypeFeatureは頭から処理を実行するという逐次実行型なので、定義を後ろに書いてもどうにもならない。Fが複数並んだら、自動的に合字を作るという手続きも、FF合字とFFI合字がある場合、先にFF合字を処理してしまうとFFI合字が処理できなくなってしまう。当たり前だけど……まぁ、そこもともかく、それで実をいうとfeature Trigger {rules;}Trigger;もlookupと記述されていないだけで，実体はlookupなので、OpentypeのFeature自体は実はこのlookupの手続きの塊ということにもなるんだけど、またそこも話し始めると長くなるからなぁ、まぁ、いいや、そこもまたそのうち。いまはまぁこういうことで、とりあえずの完成品は以下のようになる。
それで、まぁ、案の定といったところなんだけど、イラレの日本語版ではGPOS Lookupが機能しない。素直にGSUBのほうで弄った方が良かったか……まぁ、もう、それじゃもう少し改良していくという方向で……といったところなんだけど、なんかまた大分長くなってきたので……続きは次回。以下次号。
フォントの解説
Acta 2010年。社会主義政権を打倒して労働市場を自由化し労働組合を粉砕した南米の新自由主義軍事独裁政権……って、まぁ、あの悪名高いチリのピノチェトのことなんだけど、嘗てそのピノチェトを熱烈に支持していたというチリの保守系の新聞La Terceraのために、21世紀になって新たに設計されたフォントファミリー。デザイナーはDino dos Santos。フォントのデザインにシカゴ学派っぽさがあるのかどうかというそこのところはともかく、保守的でありながら新鮮さもあるという感じのまさに新自由主義っていう雰囲気のフォント……って、またいい加減なこといってるけど……単純にデザインだけで判断するならいいんだけど、そういう事情なので使いどころを間違うと酷い嫌がらせにはなるという……え？ 気を使いすぎ？ Stephen Colesによるとタイトルロゴからセリフがなくなっていた頃のNewsweekでは、Actaが使われていたらしいんだけど……え？ そういう嫌がらせ？ いやまぁ、あの当時は紙をやめるとか言ってみたり、やっぱやめるのやめるわと前言ひっくり返したり、いろいろとっ散らかっていたこともあって、元に戻ったのはそういう理由じゃ無いんだろうとは思いたいんだけど……まぁ、気にしないでくれるというのならば、それはそれで構わないけど、知らなかったとか騙されたとかいって後から文句を言うのだけはホントやめて欲しい。
Bill Corp Narrow 2015年。Bill Corporate Narrow。バウハウス最後の巨匠ことMax Billの名を冠するジオメトリックサンセリフ。Bill Corporate Mediumを元にOliver Jeschkeによって制作された書体。細部をちゃんと見ないとFuturaと区別がつかないかもしれないけど、Futuraに比べるとオーバーシュートは控えめでFuturaにはない馬鹿みたいに細い超極細のスタイルもあるので、大きなポスターに大きな文字をデザインしなければならない場合にはFuturaよりも役に立つ。
Davison Art Nouveau 1967年。この書体に関しては以前にチョロッとだけ紹介したことがあったんだけど、今年の始めにFlorian Hardwigによる詳細なテキストがFont in Useにポストされていたので……まぁ、おいらの駄文より遥かに素晴らしい内容なので、詳細に関してはそちらをお薦めしておく。
Helvetica は有名だから説明はいいよね？
Helvetica Now まえにも解説したからこれもいいよね？
ITC Tiffany 1973年。Ed Benguiatによって設計され、U&lc.の創刊号が初出。大きく広がったセリフ、高いコントラストと良い感じのカーブ、特徴的な尖りがバランスしていて、サイケデリックな雰囲気満載のThe70年代といった感じのフォント。デジタルのものはBitstreamとAdobeが手がけていたけど、オルタネイトグリフが足らないのと、デジタルの特性上良くも悪くもフラットになってしまった感はあるので、オリジナルの持つ躍動感が薄れて残念な感じ……いや、良いとか悪いとかってことを言いたいわけじゃないんだけど、まぁいいや、あと、残念繋がりで言うとAdobeがアウトラインを起こしたはずなのにITCのつくものは権利関係でグチャグチャになってしまっているのかどうなのかそこのところはよくわからないけど、何故か現在はAdobeのフォントクラウドのAdobeFontでは利用できない……とか、そういう問題もある……まぁ類似書体も多いので、よっぽどコレじゃ無いとダメみたいな理由でもなければ、困らないだろうという判断なのかも知れないんだけど。
Mutable 2023年。Paulo Goodeによるヴィクトリアンスタイルのお洒落書体。ネットの記事だったと思うのだけど本人がDavison Art Nouveau に触発され……みたいなことをいったら、すかさずEd BenguiatのITC Tiffanyじゃないの？ みたいな突っ込みがあって……そんなことでクスッとなってしまったということだけが印象には残っていたんだけど、今探したんだけどその記事が見つからない。相変わらずどこで見た記憶なのかさっぱりよく覚えていないので、この話も俺の脳味噌のどのあたりのニューロンが改竄されているのかということはよくわからない。まぁ、そこはともかく、このフォントはセンスの良さで定評のあるGoodeらしいお洒落なデザインのディスプレイフォントで独特のフォックステール……って、テールの先の狐の尻尾みたいに丸まったところをこう言うのだけど、まぁ、そこが印象的という評価。豊富なスタイルに異体字がたっぷり詰まっていてグリフの数は1スタイルあたり2400を超えるのでこれらを組み合わせたパターンもまた膨大。ということなのでユニケースなブランディングにはうってつけのフォント。出たばかりということも合って早い者勝ちということもあり、その手の用途で使用するなら今年一推しです。
SF Soft Numeric AppleのOSにデフォルトでインストールされているフォントでTFNを正しく書くと「.SF Soft Numeric」。ドットで始まるので、お察しの通りデータがインビジブルなため通常のアプリケーションからの利用は難しい。アルファベットの大文字からBCEFGJQTUVWXYZを除いた12文字とそのスモールキャップと、数字と、あと記号が16進1桁個だけで構成されているのでカレンダーはおろか、完全にOSでの時刻表示にしかつかえないというシンプルなサンセリフなのだが、数字のヴァリエーションはそこそこ豊富でアラビア数字とアラビアの数字を2種類、それにインドの数字とビルマ数字、クメール文字の数字グリフと、それらのグリフの幾つかの異体字も含めて構成されている。そこまでするなら漢字やギリシアやシャム文字なんかもあって欲しかったというところなのだが、まぁ、戦前じゃあるまいし漢字を時刻表示に使う機会って、ほとんどないからなぁ……って、まぁ、そこはともかく、それでこのフォントデータが内部的には75ものフォントマスターで形成されているので幅と太さと、それにソフトさとグレードなどもバリアブルに細かくコントロール出来るようにはなっている。結果、これらの4つの軸によって生成されるインスタンスのバリエーションは、なんと毎日入れ替えても1年は持つというほどの量に達する。ただ、OSの環境設定にここを調整する項目が見当たらないから、それをしたければ直接システムに手を突っこんでプレファレンスをゴリゴリと書き換えるという危険な作業が必要にはなるのだけれど。
この記事が気に入ったらサポートをしてみませんか？