今回は游明朝体の漢字について書きたいと思います。どの書体でもそっくりに見える明朝体の漢字は，じつは書体によって違っています。このサイトのこのページを読んでくださるような，ふだんから書体に対する意識が高い方の「そりゃそうだろう」という声が聞こえるようです。

さまざま明朝体の漢字

左から，石井細明朝，岩田細明朝，本蘭明朝（以上写研書体），ヒラギノ明朝体，游明朝体です。石井と岩田は，それぞれとても個性的。それにくらべると，本蘭，ヒラギノ，游明朝体は，けっこう似ています。ほとんど同じデザインルールを持っているようにさえ見えますが，ヒラギノや游明朝体が本蘭明朝をマネたわけではありません。「アキを均等に」「字面をそろえて」「ベーシックな明朝」を書こうとすると，こんな風に骨格が似てきてしまうのです。
これほど似ている３つの書体も，よく見ると，やはり個性を競っています。点がいちばん長いのがヒラギノ。ハネがいちばん長いのがヒラギノ。ハライの曲がりがいちばん少ないのがヒラギノ。ウロコの形がいちばん直線ぽいのがヒラギノ。ウロコがいちばん大きいのがヒラギノ。ヒラギノも個性的です。
游明朝体は，点が短くて，本蘭やヒラギノにくらべると角度が自然です。ハネも小さめ，ウロコの大きさもひかえめで，ハネ先やハライ先を丸くしています。こうしたエレメントの処理をすると，メリハリがなくなるというデメリットもありますが，落ち着いた印象をあたえる効果があります。大きく，ただし細く書いた文字を小さく表示しているような印象をあたえるかもしれません。
縦画と左ハライのあいだの風通しがいちばんいいのも游明朝体です。パーツ同士が近づきすぎて，おたがいに干渉しないようにしています。対称的にヒラギノは，パーツ同士が近づいて少し干渉しあっても，パーツを大きく見せようと書かれています。
游明朝体のハライは柔らかく，３つの書体のなかでいちばん曲がっています。ウロコの形もいちばん丸く，その頂上は曲線でできています。游明朝体の丸みや柔らかみの印象は，こんなエレメントからきています。

全角欧文というのは一見地味ですが，これが結構悩ましい存在です。

游明朝体の場合，gやpのディセンダーなどは半角（プロポーショナル）欧文のままだと仮想ボディからはみ出てしまいます。したがって縦組みの時に次の文字にぶつからないような工夫が何か必要になってきます。対策として以下のような事が考えられます。

（1)文字のデザインは変えないで，仮想ボディからはみ出ない程度にY方向にシフトする。
（2)これらの文字について組版に影響がでないようデザインし直す。（ディセンダーを短くする。）
（3)何もしない。

まず（1)の方法では，横組みの時にラインが揃わないことにもなります。それはそれで問題がありそうなので採用出来ません。（3)は潔いとはいえますが，何もしないということそれ自体は何の対策にもなっていません。
従来から採用していたのは（2)でした。その結果，半角（プロポーショナル）欧文に較べて全角欧文はディセンダーが寸詰まり気味の形をしていました。半角（プロポーショナル）欧文と全角欧文とでデザインが異なっているというのは，好ましいことではないのではと感じつつも，そうするしかないという事情があったわけです。
游明朝体の全角欧文も当初は，ディセンダーを短く処理した形のものを用意していました。しかしフォントフォーマットをOpenTypeにするということが決まり，状況が変わりました。

游明朝体の全角欧文。
半角（プロポーショナル）欧文とデザイン共通のため，仮想ボディからはみ出てしまう

OpenTypeフォントには縦組みの時のY軸方向の文字の位置を調整する機能（VORG）があります。この機能を使えば，全角欧文のデザインを変えなくても済むのではないかと私たちは考えました。

左はOTFの機能（VORG）が組み込まれない場合，または実装していてもアプリケーションがサポートしない場合。
右はVORGがフォントに実装されていて，アプリケーションがサポートしている場合。

しかし，OpenTypeの機能に頼るということは，アプリケーションがその機能をサポートしていれば問題ないのですが，サポートしていない場合は，VORGテーブルは無視されますので場合によっては次の文字にぶつかってしまうようなことが起こります。社内で検討しましたが，結論はすぐにはでませんでした。しかし，ここは思い切ってこの機能を游明朝体に組み込むことに決めたのでした。（既に発売されているOpenTypeフォントには大抵VORGテーブルは組み込まれています。MacOSXにバンドルされているヒラギノOTFもしかり。一度試されるといいと思います。）

『鈴木勉の本』の本文を游明朝体で組むことが決まったとき，制作半ばだった游明朝体にはまだ欧文がありませんでした。欧文がないということは，１２３といったアラビア数字もないということで，それでは一冊の本の本文組などできません。

急いで欧文を作らなければなりませんでした。そこで，これまで明朝体と合わせる欧文として実績のあったセンチュリー・オールドをベースにすることに決め，游明朝体に大きさと太さを合わせた欧文を作ったのです。…そしてある人から「今どきセンチュリーなの？」と言われることになったのです。

『鈴木勉の本』制作時の游明朝体の欧文

私たちは，「たしかに今どきではないかも…」と思いながらも，センチュリーと明朝体の「相性」，そしてセンチュリーと明朝体が一緒に使われた「実績」について，あらためて調べてみました。
まずは「相性」。たてよこの線の書き分け方が，センチュリーと明朝体の漢字はよく似ています。センチュリーの線端についたケルンやビークは，明朝体の漢字のエレメントと同じくらい様式化されていて，筆や彫刻刀の名残はあまり感じません。それに，もともとエックスハイトが高い書体なので，小文字が単体で文中に現れてもそれほど小さく見えないという組版上のメリットもあります。センチュリーと明朝体の相性はかなりいいのです。
「実績」はというと，センチュリーは今でも写植の多くの明朝体（石井，本蘭，大蘭，岩田などなど）の標準欧文とされています。特別な指定をしない限り，文中の欧文にはセンチュリーが使われます。
もうひとつ忘れられない実績があります。英語の教科書に使われていた欧文書体の印象をぼんやりと覚えている方も多いのでは？それもおそらくセンチュリーです。

センチュリー・スクールブックが使われた教科書

センチュリーと明朝体の相性や，実績などを考えると，「今どきセンチュリーなの？」というコメントが，センチュリーの古さや資質を問うものではなく，あたらしい明朝体にあたらしい欧文をあわせることをしなかった私たちに向けられらものだとわかります。

私たちは，センチュリー系ではない，もっとちがう欧文を游明朝体のために用意することに決めました。

※オリジナルのセンチュリーと，明朝体と合わせるためのセンチュリーは，似て異なるものだそうです。このあたりは森澤茂さんがお書きになった『文字百景077　センチュリーをあなどるなかれ』（朗文堂刊行物）ですこし触れられています。センチュリーと一口で言ってもいろいろあることがよくわかります。

游明朝体は，ゆったりとした漢字と小振りなかなを組み合わせた今までにない書体です。この游明朝体にはどんな欧文が合うのでしょうか。私たちはこんなふうに考えました。

１）各文字の文字幅に少し差をつける
文字幅は，C・D・O・Qなどを広く，B・E・F・Sなどを狭くデザインすることにしました。いわゆるオールド・ローマンのスタイルに従っています。游明朝体のかなも本来のかたちを尊重したデザインなので，こうしたスタイルがふさわしいと考えました。

上：旧游明朝体欧文　下：游明朝体欧文

２）カーブは柔らかく，スッキリとしたものにする
漢字と仮名がゆったりとした線質なので，欧文もそのイメージに合わせました。

左：游明朝体「の」　中：旧游明朝体欧文　右：游明朝体欧文

３）エックスハイトを低く，ディセンダーを長くする
文章の70%ちかいと言われる仮名の大きさと，欧文のハイトを関連づけることにしました。游明朝体のかなは小さめです。それに合わせてエックスハイトを低くしディセンダー・アセンダーを長くすることにしました。

上：旧游明朝体欧文　下：游明朝体欧文

４）アラビア数字のセットは半角にする
和文組版は全角が基本となっていますので，使用頻度の高いアラビア数字は，扱いやすい半角のものが好まれてきました。游明朝体もそれにしたがい，アラビア数字のセットを半角としました。欧文のデザインで，「さきに文字巾ありき」というのも変ですが，使いやすさを優先しました。

中央：游明朝体　下：ヒラギノ明朝体

イメージはおおよそ固まりました。次回は実際の制作の仕方について書く予定です。

游明朝体に合わせる欧文のイメージはどうやら決まりました。それからの作業の進め方はこんな風です。

1）平ペンのスケッチ

平ペンを使って，自然な手の動きを活かしながらスケッチを書きます。その中からイメージに近い文字を選びます。

2）鉛筆の下書き

平ペンの下書きを土台にして，今度は鉛筆を使って，より丁寧な下書きをします。細かなエレメントもこの段階で決めていきます。

鉛筆の下書き

3）アウトライン制作

鉛筆の下書きをスキャンして，フォント制作ツールでアウトラインデータにします。結局は手で直すことになるのがわかっているのでトレースソフトは使いません。太さもここで決定します。大文字・数字＞小文字＞仮名という設定をして，大文字・数字はあまり太くなりすぎないようにしました。

フォント制作ツールの編集ウィンドウ

4）サイドベアリングの設定
最後の作業です。それぞれの文字のサイドベアリングを決めてあげなければなりません。単語になった時の文字と文字の間のスペースを決めるとても大切な作業です。和文と合わせること，そして本文用であることを考え，すこし広めの設定にしてあります。全体のバランスをとりながら，細かな調整を繰り返します。

游明朝体の欧文はこんな風に作られました。漢字とかなのイメージを考慮したオリジナルデザインです。和文組版のなかで使われることを考えたライン・ウエイト・カウンターに設計してあります。游明朝体のゆったりとした和文の中で，目立ちすぎず，なじみすぎない欧文に仕上がったと思っています。

游明朝体の欧文

OpenTypeフォントフォーマットは，TrueTypeのsfntフォントファイルフォーマットにPostScriptフォントデータのサポートが追加されて成り立ったそうです。その成り立ちからも判るように，OpenTypeフォントというのは，アウトラインデータのフォーマットの違いからPostscript（CFF)ベースのOpenTypeとTrueTypeベースのOpenTypeの二つに分けることが出来ます。『游明朝体R』，そして『游築初号ゴシックかなファミリー』はいずれもCFFベースのOpenTypeです。今回は何故そうしたのか，それによって生じた功罪について大雑把に触れてみたいと考えます。

PSフォントの基本メッシュサイズは1000/EMです。游明朝体R（そして游築初号ゴシックかなファミリー）の全角キャラクター（漢字，仮名，全角の約物，記号など）は1000メッシュという限られたグリッド上にベジェ曲線を形成する制御ポイントを置いて文字の輪郭を描き出してます。一方TrueTypeは1024/EM，あるいは2048/EMが基本です。その限りに於いては，TrueTypeの方が高精度な書体開発が可能といえるかもしれません。またTrueTypeのヒント処理もなかなか優れていまして，TrueTypeフォーマットが持っている本来の表現能力は率直に高いと思います。

ところで，游明朝体Rのように当初どういったフォーマットでフォント化するのか未定であるような場合，何よりもデザイナーにとっての制作環境が優先されるので，高解像度のメッシュサイズで制作が進められます。その場合，フォント化の過程で場合によっては丸め誤差が生じて，微妙に変型することがあります。当然変型していないかどうか全文字確認し修正を行う必要があります。游明朝体Rは高解像度のメッシュサイズで制作されましたので，この変型の確認と修正にかなりの時間を費やしました。

游明朝体Rや游築初号ゴシックかなの制作にあたってはPSフォントと同様のベジェ曲線をハンドリングして文字を作り出す制作ツールを使用しました。TrueTypeフォーマットもベジェ曲線で文字を描き出すことには違いないのですが，一般に2次スプライン曲線と呼ばれるのもので，PSフォントのそれとはイコールではありません。デジタル字母をフォント化する過程（コンバート）で発生する変型もPSフォンデータにコンバートするよりも大きくなることが予想できる上に，それを修正するためにTrueTypeのベクトルデータを直接編集するということは私達には何一つノウハウと呼べるもののない未経験の領域でした。Postscriptフォントを単にTrueTypeフォントにコンバートしただけでは，とても満足のいくものは出来ないことはよく知られているところです。

結局フォントフォーマットをOpenTypeにするということに決まってから，いつしかTrueTypeフォントの必要性について考えることもなくなりました。弊社の製品がCFFベースのOpenTypeであるのは，TrueTypeフォントデータをネイティブに扱うための制作環境ではないことや，マスターデータとなるデジタル字母からTrueTypeフォントデータへのコンバージョンに無理があることなどなど，色々な意味で弊社にとってはTrueTypeは敷居が高かったからということになります。

しかしながら，MacDTPはともかく，WindowsDTPにおいては事実上の標準フォントフォーマットはTrueTypeでした。今でもデジタル署名を施しただけで中身は従来のTrueTypeフォントと変わらない「OpenTypeフォント」が見受けられます。こういった「OpenTypeフォント」であれば恐らく，今まで業務に使用されてきたアプリケーション上で問題なく動作するだろうと思われます。一方，今回弊社がリリースした『游明朝体R』や『游築初号ゴシックかなファミリー』，あるいは他のフォントベンダー様がリリースされているPostscript（CFF)ベースのOpenTypeフォントはどうかというと，問題なく動作するとは限らないのです。例えば縦組み組版が正常に行えないというようなことがあるかもしれず，動作確認を行う必要はあります。厳密にいえば，そういったアプリケーションはOpenTypeに対応していなかったということになりますが，TrueTypeベースのOpenTypeを使っていて問題なければ，普通はその違いを気にすることないでしょう。

弊社としては，誤解を招く恐れがあるということで，「使用するための必要条件」の項目内容を一部改変しました。個別のアプリケーション上での動作確認は，各アプリケーションのサポート窓口に問い合わせていただくことになりますが，いずれはユーザー様同士がお互い様々なレベルの情報交換ができるような場を提供できればいいなとも考えています。