レタースペーシング
⚠︎タイポグラフィデザインに係るレタースペーシングに関する情報です。 極端な内容・真偽不明の情報でないかご注意ください。ひとつの情報だけで判断せずに、さまざまな媒体のさまざまな情報とあわせて総合的に判断することをおすすめします。
アルファベットのデザインは大抵の場合はグリフを格好良くデザインするだけでは作業の半分も終わらない。アール・ブリュットな文字でもない限り普通、通常、一般では、それをしようと思ったら見えているところよりも実は見えていないところのデザインのほうが余程大切で、つまりは文字と文字との隙間……空間をどうするかということが書体の見た目にものすごく大きく影響する。このことをスペーシングと言ったりする……日本語で言うところの字の詰めだのアキだのというようなことだが、和文のデザインは一部の例外を除いて、正方形のボディを並べて文字を組むのに対して、欧文の場合は等幅フォントでも無い限り文字の左右幅が一定では無く、また文字の側面も斜めだったり丸だったりするものだから、いろいろと面倒くさいことを考える必要もある。日本語の字詰めが単純だと言うつもりも無いが、ことフォントデザインに関しては、四角いハコを丸く収めればなんとかなる……まぁ実をいうとその考えだけだと漢字しか使わない中台の場合、かなでリズムのとれる日本語と違って差し障りがあることもあるのだけれど、それはともかくそういった感じの和文活字と比較して、アイが狭くてダブルが広いという感じに、字によって幅の決まっていない垂直方向に伸……いや、まぁ、この話は長くなるからいいや、とにかく活字の幅も空くスペースも大きく違うので詰めの考え方が和文活字のようにならないのでちょっと面倒くさい。というわけで文字に限らず安定して美しい視覚パターンをつくるのにもスペーシングの考えかたはかなり重要だ。
さて、まぁ、で、文字の場合グリフの周りのアキ……レタースペースといったりもするけど、その部分をコントロールするための考え方の要件というか重要な要素というものは大きく分けると２つあって、それがメトリックのサイドベアリングとカーニングだ。
まぁ、わかりやすく言えば全体の隙間のバランスと１組づつの文字の隙間をどう扱うかというおはなしなのだが……これは余裕があればあとで解説するかもしれないけど単語間のスペースと文字の間隔をどうするかというワードスペーシングの話や字の並んだ行の隙間をどう調整するかというラインスペーシングの話とはまた別なので誤解無きよう。とにかく、まぁ、いろんなところにいろんな透き間の話があるから、いろいろ混乱するかも知れないけど、多分多くのデザイナーにとってはあとの話の方が重要だよね？ 今回のはなしはその話とはまったく関係ないとまでは言わないけれど、まぁ、ほぼほぼ関係はない。実をいうと綺麗にちゃんと設計されているしっかりしたOpentypeフォントを使っている場合は、ここはもうキチンとビルディングされているはずなので、バリアブルフォントのオプチカルサイズに対応しているアプリでは、フォントサイズを変更すると自動でサイドベアリングも変更するようにはなっているから今ではユーザーレベルではまったく気に病む必用も無いようにはなっている。まぁ、というわけで、ここから先は多分相変わらずの無駄知識だ。
それで、説明するに当たって材料はあった方がいいので用意したのがタイトルにも使っている上のフォント。何と比較しているつもりなのかはわからないが、とりあえず比較的クラシックなプロポーションで、自作したもののなかではこれでもかなり比較的にまともそうに見えるものを用意した。といってもこのフォントも小文字がないのに数字グリフの種類だけがやたらと多いというおかしなことにはなっているけど、まぁそのあたりもご愛敬だ。本当は小文字もあったほうが良いのだけど、そこをやり出すと話がさらに長くなって終わりそうにないので、まぁ、これくらいで勘弁して下さい。
サイドベアリング
さて、簡単に言うとメトリックはまぁグリフが収まる活字の左右巾で、サイドベアリングというのはそのグリフの左右最大巾からのアキになる。つまり文字とグリフのサイズの差分にあたる。アルファベットの場合文字は左から右へ進むので、文字アタマがLeft sidebearing ケツがright sidebearing になる。これらの理想的なサイズを決定するのは感覚に依存する部分が非常に多いので困難で時間がかかる作業……と教科書的には書かれるのだが、考え方は単純で字を構成する塗り潰した面と塗りつぶされていない面に対する比だ。もちろんフォントにはいろいろな形のグリフがあるので黒いところの面積も違うし形も違うしで、サイドベアリングのサイズも当然全てのグリフで同じにはならない。おまけに数値的な比が見かけのイメージとまったく合わないという場合は往々にして存在する。まぁ、当たり前だけど。
というわけで、大雑把には、この面積比が文章のどこを出鱈目に切り取って持ってきたとしても空間が揃っていればOKという考え方でいいのだけれど、テキスト画像をガウシアンフィルタにかけると綺麗に平滑化する的な数値的なおはなしではなく、あくまで見た目が等しく見えるということが優先される。まぁこれも当たり前だけど。ただ、あまり空間、空間というと、たしかスイスのタイポグラファーでブックデザイナーのヨースト・ホフリ先生は文字の中の空間が等しいみたいな表現は、どこからどこまでが文字の中の空間なのか感覚的に把握しづらいこともあるから光を当てたときに見える光学的等しさを基準と考える方がいいみたいなことを言っていたのだが……まぁ、いずれにしろデザイナーが等しいといっているときは大抵数値的、物理的等しさのことをいっているわけではないということにだけは注意する必要はある。
さて、で、具体的にはどうするかというと、これも、文字にはあまりにもいろいろな形があるので、闇雲に始めると後で収拾がつかなくなる。いろいろな始め方はあるけど、教科書的に言うと最初は両側が垂直に切り立っている大文字のHから並べる。まぁ、本当は小文字のｎから始めた方がいいのだけど、このフォント大文字しかないからね。
サイドベアリングは上の図のフォント作成ソフトの画面ではハイライトしている数字のところと、その上のところで設定する。この図はFontLab7だけれど他のソフトでもやることはほとんど変わらない。大抵のフォントは左右にサイドベアリングがあるけど、この仕様のためサイズの違う文字や違うフォントをアタマ揃えしたときに文字のアタマは絶対に揃わないようになっている。絶対にだ！ まぁ下の図のような感じになる。別に変だと思わなければそこまで気にする必用も無いが、こういうことを嫌ってLeft sidebearingがゼロになっている特殊なタイトル用フォントというものもある……にはあったけど、そのフォントを使うと今度はケツ揃えがうまくいかないうえにセンター揃えがセンターにも揃わないという不幸な事態が発生する。まぁそういうところにもちゃんと気を使いたいのならば、一行一行ちゃんと見ないと駄目だよっていうおはなしでもあるのだけれど。
このサイズをどれくらいにした方が良いのかについては、その文字を主にどういう用途でどのくらいのサイズで使用するのかということによっても変わってくる。今はレイアウトソフトで文字間なんて自由に動かせるので、後はお任せで極端な話ゼロでも構わないのだが、それでもそれならそれで全部のグリフが一貫して揃っていないとフォントとしては役には立たない。あたりまえだけど。まぁ普通は小さい文字やカウンターの広い文字は広めに、小っちゃく使う必要のないものやフトコロの広くない文字は狭めにする。また、当然ながら出っ張りが活字の縁に接近するセリフ付きの文字よりサンセリフの文字のほうが、ここの数値は大きくなるけどセリフ書体よりカウンターサイズを広くしたほうがいいというわけではない。サンセリフは一時期の流行りで……まぁ、今でもそういう傾向があるかもしれないけれどセリフ付きの書体よりは詰めて組んだりするからなおさらだ。
次に両側が丸くなっているOのサイズを決定する。丸い部分が出っ張っているのでHよりも幅は狭くなるというのはわかると思うけど、どれだけ狭くするかはHOHとかHHHOHHHとかHOHOHOHとかOとHだけで出来た文章を組んで、テキストの濃度がちゃんと揃って見えるかどうかで検討する。このとき個別にサイドベアリングの数値を指定しても良いのだけれど、最近のフォント作成ソフトでは演算子が扱えるものもあるので、最初に決めたHの基準からどれだけ動いているかを割合の計算式で指定できればそうしてしまったほうが遥かによい。つまり、まぁ、どういうことかというとここの数値の値の指定を =H*0.7 とか =H/1.42 とかやって、Hに対してどれだけの割合詰めた方がいいのかというのを式にして機械に計算させるのだ。割算すると端数が出るけど数値は丸められるので細かい事は気にしなくていい。まぁこうしておけば後々のトラブルも多少は回避できる。
ここまで来たら後はグリフのサイドが同じものが同じ数値になるようにしてしまう。DEF……の左側なら =H を、CやGやQの左なら =O としてしまえるフォント作成ソフトがあれば……まぁ、簡単でしょ？ 後はAVWXYと斜めのラインの文字、EFCGなど側面が開いている文字とか、まぁいくつかのパターンも同様にして纏めてしまう……現状では下のような感じ。ただ、まぁこれだとピッチのことを考慮するとかなり乱暴なことになっているので最終的には調整する必要があるけど……。
こうして出来上がったフォントで、ある程度の長文を組んでみて破綻無く仕上がって見えれば、サイドベアリングは一応完成したことになる。
カーニング
ということなのだが、さて、話はここでは終わらない。実は活版印刷の時代だったらここで終わってしまってもよかったんだけど、活字と違って……というか本当はこれ活字の時代からあった技術なんだけど、まぁそれはともかく、活字と違って、TとAとか、AとVとか、LとWとか、そのままべた組みされると他の組み合わせより文字間が広がって見えて問題を引き起こす個別の文字の組み合わせというものがあり、活字の場合はそれ以上詰められないが現代では問題無く詰められるので個別の組み合わせの文字の間隔だけを抜き取ってその部分だけをちょうど良い感じに詰めたり拡げたりしていって処理する必要がある。この一組毎の間隔調整のことをカーニングと呼ぶ。
さて、では、その問題を引き起こす個別の組み合わせというのが、いったいどのくらいの数になるかというと、捉え方や、文字のデザインにもよるけどキチンとサイドベアリングが設計された英大文字の組み合わせだけに限ったとしても、概ね120組程度には問題が起こるはずと考える人もいる。ここまで問題が起きると、もはやサイドベアリングはほとんど最初に作ったHの文字と他の文字とのカーニングの最適値という意味しかもたないが、まぁそういう考え方もできるということなので、それに従って英語のアルファベット全組み合わせ可能数26P2で割ると、どんなに健康に作られているフォントでも、カーニング抜きでは、おおよそ5組みに1組みくらいの割合でなんらかの障碍を抱え込んでしまうという結論になる。もちろんこれは大文字2文字のみを組み合わせたケースだけでのおはなしなので、2文字一組だと問題無いけど別の字を加えて3文字一組で並らべられるとなんか変とか、当然小文字のあるフォントなら大文字と小文字、小文字と小文字の組み合わせも追加され、さらには文字以外にも大文字と数字、大文字と記号、小文字と数……まぁ、キリが無いからみなまではいわないけど、そうやっていろいろと組み合わせ数を増やしていけば、ひとつのフォントで膨大な数のカーニングが処理されていなければならないということだけは察しが付くと思う。フォントを選んで文字を並べるだけでは組版としてはまったくダメダメといわれる理由がここにある……ということなので、そのあたりもう少しうまい処理ができるようにと、フォントのデータの中にその情報も一緒に記入する。いまでは標準的なOpenTypeのフォントではデータとして内部で普通に4桁ほどはカーニング処理の組み合わせ情報をもっている……よね？ まぁ、そういうことなのでこれを利用することでエンドユーザー側では、手間を要すること無く美しい組版処理が可能になり、そういうものに対する敷居は比較的低くなった……はずなんだけど。
ただ、まぁ逆に言うとフォントを作成する場合はその手間を惜しむことが出来なくなって、このあたりをちゃんと考慮していないと、後々にとんでもないことにはなる。Googleフォントのなかにはここのところがいい加減と言ってしまうと失礼だが、まぁあまり上手くいっていない書体も多かったのだが、Googleのフォントイシュートラッカーの地道な活動のおかげもあって、前より……いや、まぁ、それはともかく。
それで、このカーニングをフォントに組み込むためには、カーニングテーブルを個別の組み合わせでやはり地道に弄る必要があるのだが、闇雲に始めると本当にグリフ数の階乗をグリフ数マイナス2の階乗で割っただけの作業をしても終わらない。
そこで、まえにも説明したけど、作業を始める前に似たもの同士をまとめてカーニングクラスを作成しておくというのは大事だ。作業としては本当に間隔を弄るだけの単純作業だが、それでもバリアブルフォントを作成する場合にはちょっと注意が必要で中間マスターをいくら弄っても基準となるマスターに存在しないカーニングペアは値が0になってしまので、それがイヤならばマスターに定義する必要がある……が、逆の場合は補間が効くので必ずしも必要ではない。まぁあったほうが良いけど……まぁそこもともかく……で、そうやって、そのあたりのデータを作成するのだが、これだけやっても、クラスの割り当てを間違えていたりすると当然とんでもないことになるし、ケースによっては例外を個別に割り当てなきゃならなくなるということもある、さらにはあまり例外を作りすぎるとクラスカーニングの効率が落ちて碌でもないことにもなりかねない……と、まぁ、いろいろ面倒なことは面倒なので、フォント作成ソフトのほうでもいろいろとそのあたりを簡単に自動化したりするツールも存在することはするのだが、それでも、そのツールを使えば一発で終わりになるというほどの暢気で完成度の高いツールはない……というかそういうアルゴリズムがあれば後でも説明するけれど、アプリの方でもなんとかできてしまうので、ここで手作業する意味はまるで無い。ここをちゃんとしようとすると、全く当然の事ながら、短気な人には全然向かないという途方もない作業が待っている。いやホント。
というわけなので、もしかしたら全ての文字の組みにカーニングが施されていれば問題無いのでシステム的にはサイドベアリングは何のためにあるの？ というような発想も否定は出来なくはなくはない……のだが、残念ながら古いOSやソフトウエアではこのカーニング情報を正しく見てくれないモノもあり、さっきも言ったようにすべてのフォントが正しくカーニングペアを設定しているわけではないので互換性の問題は出る。また当然のことながら別々のフォント同士がカーニング情報をやりとり出来るようには、今はなっていないので複数のフォントを並べて組む場合やサイズの違う文字を並べる場合はサイドベアリングのアキでしか文字の空間を判断できない。
こういうことで、まぁ、外から見るとただの文字の隙間なのだが、伝統的な面からも、技術的側面からも、レタースペースの中には2つの異なったスペースに対する情報が存在する。アドビのソフトウエアには古くからそういうことを無視できるオプティカルという機能があったりもするのだが、このアルゴリズムも全然万能ではないうえに、正しくカーニング情報の書き込まれているフォントよりも賢くスペースを計算できるような解法になっているかというと、まったくそんなこともないので、その場合はフォントデザイナーの設置したサイドベアリングとカーニングの情報を……つまりアドビのメニューでメトリクスってなっている方を優先させないと、結果は芳しくないというところは……まぁお察しの通り。将来アプリケーションが自動でこの手の処理を実現できるかどうかに関しては……まぁ出来るかも知れないけど、いろいろと片付けなければいけない課題も多い。それにデザイナーが苦労して作ったスペースよりもAIが作ったスペースの方がクレバーに見えるといわれるようになったとしたらそれはそれでデザイナーの面子は丸潰れになる。
そういうことで、まだまだ文字の基本的なデザインや文字のスペーシングの問題などはこの冗長なうえに原始的なシステムと職人芸に支配されている。また、以前も言ったけどフォントデータの中にカーニング処理のような個別で複雑化しやすいグリフポジショニングルールを大量に持ち込むと場合によってはアプリやシステムをクラッシュさせることもある。過去にはこの手のポジショニングデータを内部に持たない古いフォントで、このカーニング情報をAFMファイルのかたちで外部に持たされていたのだけれど、雑なコピーを繰り返す打ちに元のフォントファイルとは離ればなれになってしまいがちで、扱いに注意が必要で、特に日本語環境では基本無くても困らない所為か、エンドユーザーレベルではまともな取り扱われ方がほとんどされてはいなかった。というかフォントのコピーがスーツケースのビットマップしか渡されないというケチな……いや、まぁ、なんでもないです。
さて、まぁ、それで、文章を読みやすくするのはもちろんフォントの字間だけを調整しただけでは全然足らない。フォントのサイズ、字間と単語間のアキの関係、1行を何文字で埋めれば最適なのかという行長、行と行の空間、さらには段落間のアキと段落と版面とページサイズからタイトル、見出しの入れ方云々とまぁ、他にもあるけど、もろもろそういったものが相互に関係し合って全体を形成しているので、それら全体との関係性からフォント自体のデザインを見直す必要も、またあったりする。まぁ、どういう文字を作るのかは、どういう風に使われたいのかということも想定しなさいと言うことなんだけど、そこまで話を拡げるとほんとうに手に余り、いい加減な話が、さらにいい加減になってワチャワチャするだけなので、とりあえずはこの辺で。あと、まぁこういうレタースペーシングに興味が湧いたら、もっとちゃんとしたことは以下の書籍がオススメ。参考文献もキチンと表記しているので、さらに深く知識を得ようと思ったらそれらの本にも是非アクセスして欲しい。こんな適当なおはなしよりも余っ程役に立つ。ホントだよ。
用語説明
Googleフォント GoogleがSIL Open Font Licenseのもとで無償提供しているWeb上でのフォントサービス。Webページのフォント表示のみならず、インストールして自分で使うことも可能。OFLでGitHubなフォントでさらに、FontBakeyのチェックを通るGoogleの要求する要件を満たすフォントが提出できれば誰でも……というとまぁ語弊はあるが、参加することに関してはオープンな仕組みになっている。
アルファベット【alphabet】アルファベットといわれると、まぁ、概ね英文字のABC……のことであろうと想像し、アラビア文字やヘブライ文字が真っ先に頭に浮かぶ人はそれほど多くはないと思うけれど、逆に単に文字のセット……つまり書記体系のことを英語でアルファベットと言うのだと思っている人も多く、これがまた面倒なことにその理解でも概ね間違っているとも、いないともいえないような感じになるので、こういう言葉をきちんと定義づけようとするのはなかなか厄介だ。言語学的にも一応の定義はあるのだけれど、ここも細部を詰め出すとかなりゴチャゴチャした話になる。まぁ、「世界で最初に誕生したアルファベットはギリシア文字でフェニキア文字のアルファベットに基づいて開発されました」みたいなことを平気で言ったりする人もいるので、あまり深く考えないほうがいいような気もする。幅広く音素をセグメントした記号のセットという意味で定義すると基本的には現在の世界では、ロゴグラムな仕組みをもつ書記体系を持つ特定の国以外……どこの国のことを言っているかはわかるよね？ まぁ、つまりは、ほとんどの国の言語がこのシステムで運用されているということになる。というわけで、広がりすぎるのでここではもう少し意味を狭めて、母音と子音が等価で表記される左横書きの概ねは丸か三角か四角かという極々単純な図形で構成されていて、言語によって発音は違うけれど、多くの字形が共通している……希英露で言うとABEHMOPTXが共通で、これは実にラテンアルファベット全体の三分の一にものぼる……というようなギリシア文字、ラテン文字、キリル文字などのグループのこと……という実にふわっとした雰囲気の定義で本人は話をすすめているつもりなのだが……笑っちゃうことにラテン文字の話しかしてはいない。
アール・ブリュット【art brut】アウトサイダーアート。ただ、まぁアウトサイダーというと病気や障害、犯罪といった要素からマイナス方向へバイアスがかかったみたいなイメージに聞こえる所為か、最近ではそういう言い方はしない傾向。広い意味では正規の教育訓練を受けていないプロフェッショナルではない人の作った作品のうちアートとして取り扱われているものと言うような意味。そういう意味では産官学連携のシブヤフォントみたいなものをアール・ブリュットとして分類して良いかはハッキリ言って微妙。さらに言えばここでやってることなんか、クルクルパーの戯言みたいなはなしなのでアールであるかすらわからない。なのでさらにいってもっと微妙。
オプチカルサイズ 光学サイズ。バリアブルフォントのバリエーションの一つとしてデフォルトでopszというタグが用意されている。このサイズの軸の目盛りはテキストのポイントサイズと単位が一致するように実装することが推奨されていて、ソフトウエアが対応していればユーザーがテキストサイズを変更するだけで自動でフォントが最適なデザインや字間になるようにオプチカルサイズを変更する。インデザインではこれが「オプティカルサイズをバリアブルフォントのフォントサイズにマッピング」のチェックがオンになっていれば可能だが、下の図のようにデザインの見た目が大幅に変化するので細かい事が気になる人にはあまりオススメしない。まぁ、このように、これに対応したフォントにはひとつのファイルにタイトル用の字間が詰まったコントラストの高い文字からキャプション用の字間の開いたコントラストを下げた文字までがパッケージされる……という態にはなっている。
オプティカル イラレやインデザインなどでは、デザイナーが自動で扱えるカーニングの選択肢を複数用意してあって、こちらは隣接する文字のデータからアドビ独自のアルゴリズムに基づき自動的にカーニングサイズを導き出すという機能。対するメトリクスというのが本文でゴチャゴチャ説明したようにしてフォントデザイナーの作ったカーニング情報にもとづき文字を詰めるという機能だ。大昔はガンガン使えといわれ、今は使っちゃダメとまでいわれるいわく付きの機能だが、こういうものも何が目的なのでどれを使うかという問題なので、ホントは自動化なんて信じないでデザイナーを名乗るならちゃんと自分の目と手を使えというのがまったくの正論なのだが、味の素と一緒で、いくら出汁からとるのが料理の基本といわれても、そもそもオマエ料理下手ッピーなんだから、おかしな拘りを捨ててせめて味の素使って食えるモノにして出せや！ といいたくなるケースはいくらでもある。過去にはまともなカーニング情報をもつフォントが少なかったため多用されていたが、OpenType以降そのあたりは徐々に改善されて現在に至る。もちろん当然メトリクスを優先すべきだが、現在でもオプティカルを用いた方が結果が遥かによいというケースも少なくはない。
カーニング 文字詰めだの字送りだのスペーシングだのトラッキングだのメトリックスだの……文字を詰めるために使われる用語には、普通の人が聞くとかなり混乱する名称が混在して使われているのでまったく以て意味がわからない。やってることは字の隙間を弄っているだけなのに何でこんなに色々な呼び方をしなきゃいけないんだという感じにもなるだろうけど、まぁ、わざわざ難しくして皆に意地悪をしたいわけではない……多分。このテキストもそうなってなきゃいいけど、実を言うとそのあたりはもうとっくに諦めている。それで、だいたいはこの手の混乱と悪習のほとんどが金属活字に由来していて、この言葉の由来もお察しの通りこの金属活字の時代に溯る。もともと、活字では文字を詰めようとしても物理的に左右のサイドベアリングを超えて文字を詰めることは不可能なので、それをするために活字の側面を鑢で削ったり活字側面より文字の端だけが飛びだした特殊な活字を利用するということがあった。もちろん一旦削ってしまったものは失敗するとおじゃんになるし、特殊なモノは壊れやすいうえにコストも掛かるので出来れば本気でやりたくはないのだが、それをするかしないかで刷り物の品質は格段にかわることには気が付いてしまったのでやらざるをえない……で、まぁ、その特殊な活字のその飛び出した部分をカーンと呼んだので、その特別な作業のこともカーニングと呼ぶようになった。
グリフ 文字。まぁ前にも説明したような気がするからいいよね？
数値的な比が見かけのイメージとまったく合わない わかりやすく図にすると下のようになる。下の左上の2つの正方形は右側が一辺√5の正方形なので左の1の正方形と比べて面積で5倍になっている。そこで、下はその右側の√5の正方形を面積で5等分した図だけれど多分5人の子供にこんなケーキの分け方をしたら間違いなく喧嘩になる。左はL字のケーキのほうがお得に見えるが、真ん中のパターンで分けると皮しかなくて何か微妙。真ん中も喰わせろと文句をいったら左のように田の字にして出してきたのだが、スカスカで喰えたものではない。もちろん面積はみんな一緒なのだが、受けるイメージもダメージも違う。
後々のトラブル 下の図のAHOと三文字を並べたときこの色が塗られている空間がそれぞれ同じに見えるというのが視覚的均等というところで、まぁ、視覚的っていうところが本当に厄介なんだけど、それはともかく、話は以下のような顛末。
大きなフォントファウンダリーなので書体の作成は分業だ。スペース調整しながらプログラムを組んでいる人と、書体のデザイナーも別なのだが作業は順調に進み納品間近となったある日、突然デザイナーの気が変わって、やっぱりAの斜線の傾きは変えて文字を活字幅いっぱいにまで拡げた方が良いなどと言ってきたとすると、Aのサイドベアリングは限りなく直角三角形に近づいていくので、単純にサイドベアリングの面積を合わせようとすればHのLeft sidebearingはAのright sidebearingの直角三角形の短い辺の２分の１の巾の長方形で決定する。そうすると、自動的にその同じサイズの長方形がそのままHのright sidebearingになるので、そのサイズからOのサイドベアリングのサイズが決定してしまい……とまぁ、そういう次第で、このフォントの場合はOがほぼほぼ正円に近いので計算すると円に外接する長方形の面積のだいたい８分の１くらいにあと足らない面積の分の長方形を左に追加した【の型をしたサイドベアリングが出来上がる。「文字の高さが７インチ、Aのサイドベアリングが１.４インチのときOのサイドベアリングの最大巾は何インチでしょう。但しOのシルエットは正円とする」みたいな問題にすれば、公文に通っていない中学生でもわかる答えだ。Aの角度を測り直す必用も無ければ、積分を持ち出す必要すら無いのだが、ただ、そうやって出した答えが一致すれば良いけど、そうじゃないと、いままでやってきたことの結果全てが台無しになる。デザイナーの不用意な一言によって社内にはデスマーチが鳴り響き、彼奴ぶっ殺してやる！ などと血走った眼で……というおはなしになるので、刑事事件に発展することのないようにどんな変更があっても困らないよう全てのサイドベアリングの関係が合理的に結びつくように設計されているのが望ましい……というような理屈。ただ、まぁ、これを今言うのもなんだけど、そうして幾何学的に正しい答を並らべても視覚的に正しくなるかというのはまた別の問題なので計算結果が正しくても視覚的な調整は必ず必要になる。さらに追加して言えば左右の空間のアキが同じに見えればそれが本当に美しさや読みやすさを担保することになるのかという問題もあるにはあるのだがそれを言い出すと今までやって来たことが本当に水の泡になるので、いま口走ったことは誰も聞かなかったっていうことでいいよね？
バリアブルフォント ひとつのフォントファイルの中にオプチカルサイズの図版のフォントのように動的に変更可能な軸をもっている書体。持たせようとすれば100でも1000でも変動軸を追加することは可能だが、まぁ当然そんなことをすればおかしな事態が発生する。ちなみに下のフォントは自作した軸とグリフの数が同じという変動軸を山のように盛った頭のおかしいフォントだがWeb上のツールで確認してもエラーは出ないのにも関わらずインストールするとアドビのソフトは確実にクラッシュする。
ピッチ これも、まぁ色々なところで、色々な使い方をされるから何のことをいっているかわからないかも知れないけど、ふわっとした言い方だと横方向の繰り返し単位の最小値。アルファベットは文字の横幅が揃わないが、かといってまったく出鱈目なサイズでOKかというと……まぁそれでもいいのだろうけど……そういうわけでもない。基準となる文字を垂直方向に分割して作ったモジュールの何個分という個数の幅のなかに必ず全てのグリフが収まるように設計されていないと非常によろしくない……と、まぁそう考えるわけ、デジタルエイジになってこのあたり相当曖昧になってるけど、活字がプロダクトであるという側面を考えると、ピッチをどう揃えるかというのはやっぱり大事な……と、まぁ、話し出すと長くなるからアレだけど、そういうことで、世の中いろいろな考え方はある。適当に何も考えず見た目でデザインしていったら、なんか偶然最終的にピッチも揃っていましたっていえるのが理想と言えば理想なんだろうけど当然世間はそんなに甘くはない。
膨大な数のカーニング まぁ、ここで疑問に思っただろうけど、そもそも活字の時代には必要無かったというと語弊があるが、おそらくそこまで気にしていなかっただろうというコトが現代ではおおきな美学上の問題になるのはどういうことかというと、大きくは、やった方が良いのはわかっているけど技術的な制約で出来なかったという、過去のわかっちゃいるけど出来ないじゃんという技術的な理由とトレンドの問題というふたつにある。技術的な問題は創意工夫で、活字の時代のデザインのフォントは現代のものに比べると字間もゆったりとしていて比較的カーニング問題を起こしにくいデザインでなお且つ、それでも問題がありそうな箇所には合字や特殊な活字がつかわれるというような仕組みになっていた。第二次世界大戦後、写真植字が普及するとメトリックのボディサイズよりもマイナス方向への字詰め処理が可能になり「詰め打ちなんか格好イイ」みたいな風潮から、デザイナーが文字をガンガン詰めだしたので、字間がある程度緩ければあまり気にならなかったので今まではなぁなぁで配慮もそれほどしていなかったこのあたりの問題が一挙に浮上する。また、写植では活字の時はわかっちゃいるけど出来ないじゃんでやらなかったところもやれるようになったので当然そういうデザインの書体も増えてくる。というわけで、サイドベアリングの問題とカーニングの問題は時代的背景や技術的背景その他もろもろいろいろなことがズレているので、考え方の指針が少々異なっていたりもする。まぁそれでも空間のデザイン方針が変わったわけではないし文字はつまらないよりはつまるほうがいいという……いや、まぁ何でも無いです。それは、ともかく、まぁそういうことなので、つまりはよく出来た書体ならばカーニングなしでもなんとかなってしまうということではある。
メトリックのサイドベアリング 字幅に対する左右のアキ。イラレとかで言うプロポーショナルメトリクスとかメトリクスというのはどちらかというとカーニングを詰め……まぁ、フォントに関する用語というのは何のことをどう呼んでいるのかというのはけっこういい加減で、もう慣れちゃったからいいけど、イラレでは、文字ツメって、なっているところが実はこのサイドベアリングを何パーセント切り詰めていくかということと同義で、和文でしか使っちゃいけない機能みたいに思っている人もいるみたいだけど、欧文でもオプチカルサイズの設定されていないフォントを使う場合は見出しの文字を同じフォントでサイズを上げると本文より詰めることになるから「文字ツメ」のパーセントでサイドベアリングを削るほうが簡単だ。１文字目の左端も前方に詰まるうえ全体がサイドベアリングサイズ以上にはマイナスにならないので文字が詰まりすぎず、どんな素人が何も考えないでやってもわりと揃って綺麗に見える。こういうことを言うと欧文の場合はトラッキングをつかえなどと偉そうにいってくる人もいるけど、多分その人はここの仕組みがよくわかっていない。トラッキングで詰めると文字左にサイドベアリング幅がそのまま残るからサイズを上げると一文字目の左端が右に下がってくるうえにツメだけは詰めようとするといくらでも詰まるので基準がなくて碌なコトにならない。まぁこの辺は使い分けで使っちゃダメとまでは言わないけれど、このあたりの仕様は……まぁもう慣れちゃったからいいけど。
この記事が気に入ったらサポートをしてみませんか？