★一言もの申す（毎週月曜日更新）
1997年10月分。古いものは、下へ下へ。
第７回●ビットマップフォントのデフォルメ・２ 1997. 10. 27(月)
前回、ビットマップフォント特有の問題として、ジャギーについ
て触れたが、さらに厄介なのが、線のカーブの見え方である。
まず、下のパターンを見てほしい。
16ドットゴシック体の右払いを拡大したものだ。
■ ■ ■
■ ■■ ■■
■■ ■■ ■■■
■■■ ■■ ■
左が正しい、というか、私の使うパターンである。
タイプフェイスをスキャナで読んで圧縮した場合、中央や右のパ
ターンが出てくるかも知れない。ということは、文字のフォルムと
しては、その方が忠実に再現されているわけだ。
しかし、少し離れて線のカーブを見てみよう。
中央のパターンは、曲線というより斜線のようだし、右のパター
ンでは、カーブの先端が下を向いているかのように見える。
簡単なことのように思えるが、世間で使われている12〜16ドット
フォントには、このような文字が多く見られる。
前回書いた、文字のフォルムより、規則性を優先するというのは、
こういう場合に必要なルールなのだ。
点画の少ない漢字ではまだしも、複雑な漢字になるとつい忘れが
ちになるが、読み易くするためにはおろそかにできない。
プリンタには、「600dpi相当」とか「1200dpi相当」という表示
があるが、これはそれぞれ、300dpi、600dpiのデータを２倍に拡大
して、隙間のドットを補間するものである。中には、若干の例外も
あるが、おおむねそうだ。
コンピュータ側のラスタライズ時間の節約、データ転送時間の節
約、プリンタのメモリ節約等、解像度が半分なら、どれも４分の１
程度に減らすことができる。
しかし、ビデオのモザイクが、決して完璧には取り除けないよう
に、足りないデータ（正確なドットのセット、リセット情報）は、
求めることができない。プリンタメーカーは「スムージング技術」
とうたっているが、実際には、単に周囲１ドット程度の情報から補
間データをつくっているに過ぎないのだ。
線と線の交差するところ、直角に曲がるところは、スムージング
によって、余計なドットが打たれ、シャープさを失ってしまう。
また、「文」等、曲線同士の交差する場所では、カーブそのもの
が歪んで出力されてしまう。その傾向は、当然ながら低級数の文字
ほど強い。
どうしても、ジャギーが目立ってしまう時以外、スムージング機
能は使わないことを、お勧めする。
前回は図が無くて分かりにくかったので、ドット数と引ける線の
数について、もう一度まとめておこう。
●○●○●○●○●○●○●○●○●○●○●○●○ ←24ドットは12本。
線幅が２ドット
●●○●●○●●○●●○●●○●●○●●○●●○ ←でも８本引ける。
●○●○●○●○●○●○●○●○ ←16ドットでは８本しか線が引ける。
線幅が２ドットなら、
○●●○●●○●●○●●○●●○ ←わずか５本となる。
●○●○●○●○●○●○ ← 12ドットでは、当然６本となる。が、
線幅２ドットでも16ドットと大差ない
●●○●●○●●○●●○ ← ４本も線が引くことができる。
16ドットで明朝体がつくれれば、12ドットでもなんとかなるとい
う『道玄坂12』（12ドット太明朝体）の秘密が解き明かされたわけ
だ。
さて、予告したビットマップフォントの組版について考えてみよ
う。
ビットマップフォントには、文字間、行間とも、それぞれ２、な
いし４ドット空けて組まれる場合と、ビッシリ詰めて組まれる場合
とがある。
しばしば登場するが、JIS X-9052-1983「ドットプリンタ用２４
ドット字形」は、24×24ドットの枠いっぱいにデザインされている
ので、文字間、行間を空けて組まれることを想定している。その場
合は、罫線をつなげるためソフト側の対応が必要になる。
ディスプレイ表示用の16ドットフォントは、実質15×16ドットで、
文字間はビッシリと詰めて、行間を４ドット空けるのが通例だ。実
際は、表示行数を確保するため、行間を詰めて表示される場合が多
く、Windowsのシステムフォント等は、15×15ドットで設計されて
いる。
16ドットや12ドットでは、１ドット小さく設計するだけで、ずい
ぶん文字が小さくなってしまう。
Windowsもそうだが、Macintoshで、漢字Talk6.0.7から、漢字
Talk7になったときに、システムフォントが異様に小さくなったこ
とに、違和感を感じた人も多いだろう。12×12ドットが11×11ド
ットになっただけだというのに…。
文字はなるべく大きく、かつ表示文字数を稼ぐ。そんな方法はな
いだろうか。
枠いっぱいにデザインしながら、文字間、行間をビッシリ詰めて
も読みやすくなる方法だ。
それは、縦線を枠の右端、左端に引かず、横線を枠の上端、下端
に引かないことだ。左右の端には、横線と右払い、左払いの先端、
終端だけが来るようにし、上下の端には、縦線と右払い、左払いの
先端、終端だけが来るようにするわけだ。
無論、文字によって例外もあるが、線が足りないからといって、
むやみに枠の周囲に線を引くと、その文字だけが大きくなってしま
うので、注意が必要である。
※第５回『似ているって、なんだろう？』補足
アナウンサーで似ているシリーズで、CXの佐藤理佳と最近見かけ
ないが（失礼）女優の森下愛子は似ていると思う。というのを書き
忘れていた。大した補足ではなかったか…。
第６回●ビットマップフォントのデフォルメ 1997. 10. 20(月)
ビットマップフォントを数多く手がけたデザイナーといえば、タ
イプバンクの故・林隆男氏だろう。
氏は、低級数のビットマップフォントでも、タイプフェイスと同
じように、文字のフォルムや組版を重視していた。
まだ、16×16ドットの漢字など、読めさえすれば良い、という時
代にである。
しかし、私の考えは多少異なる。
12ドット以下では制約が大きく選択肢がほとんどないし、32ドッ
ト以上では、桑山弥三郎氏の言葉通り、書体としての個性が出せる
ので、16ないし24ドットに話を限定しよう。
例えば、タイプフェイスをスキャナで取り込んで、24ドットに圧
縮したとする。当然、ノイズが出てガタガタになるが、そのノイズ
を手動で取り除いて行ったとしても、デザイン的にまだ不足してい
るものがある。
文字のフォルムは、その時点で可能な限りオリジナルのタイプフ
ェイスに近づいたといえるが、完成品ではない。
残りの仕上げの部分には、やはり、多少のデフォルメが必要だと、
私は思う。
具体的にいえば、明朝体の横線に右端には「うろこ」があるが、
長い線には、大きなうろこ、短い線には小さなうろこがあって、タ
イプフェイスでは、何段階にも細かく描き分けられている。
ところが、ビットマップフォントでは、その自由度はずっと低い。
24ドットでは、普通サイズが2×1ドット。小さいものは1×1ドット。
大きいものでは、5×3ドットの２等辺三角形。実際のうろこの三角
形の辺は右の角度の方が小さいが、これを忠実に再現するのは、ほ
とんど不可能だ。それを、３つのパターンのどれかに収めるのは、
一種のデフォルメであろう。
明朝体の右はらいの末端の線の太さも、デザインのポイントとな
る。24ドットでは、実際には２ドット分の太さしかないが、JIS
X-9052-1983「ドットプリンタ用２４ドット字形」では、３ドット
もの太さがある。太い部分をより太くするのは、明朝体らしさを出
すには不可欠だと思う。
横線は、視覚的な調整を無視して、どんな場合も底辺と水平に引
く。文字のフォルムが崩れる場合には、タイプフェイスとは違う理
論でバランスをとる。そんな、強引なルールも必要となる。
線と線の間は、最低１ドットは空けなければならないので、16ド
ットでは８本。12ドットでは6本しか引けない。24ドットの明朝体
では、縦線が２ドット幅なので、16ドット同様、縦には８本しか引
けないことになる。縦線の多い漢字では、所々１ドット幅にするの
だが、どの線を１ドットにするのかは、ルールをつくってしまおう。
タイプフェイスのように、線幅を微妙に変えられないので、太い
線と細い線では、差が２倍になってしまう。ある一定の太さを基準
に、それ以上なら２ドット、それ未満なら１ドットとするのは、私
には疑問がある。１本の線でも、密集している部分では１ドット幅、
空いている部分では２ドット幅にする。というのもありだと思う。
また、ビットマップフォント特有の問題として、ジャギーがある。
ワイヤドットプリンタやCRT表示では、点が円形だったり、正方形
であっても点の一つ一つがにじむが、熱転写プリンタや液晶表示で
は、点が正方形でにじんだりもしない。
そうなると、斜線や曲線がガタガタになってしまうので、線をな
めらかにする工夫が必要だ。
NECの16ドットフォントでは、極力曲線を排し、45度の斜線を多
用することによって、ジャギーに対処している（と思う）。
しかし、どんな曲線でも、ドットの配置の仕方によって、ジャギ
ーが目立ったり目立たなかったりするのだ。それを何通りか試行す
ることによって、曲線を使うことができる。
好みというのは、不思議なものだ。
あんな奇麗で可愛らしい角田久美子のことを、「どこがいいの？」
なんて言う人もいるし、世間では結構人気のある、工藤静香とか、
飯島直子とか、私は全くなんとも思わない。
書体デザインでも、私がごく当り前に、良いと思うように創って
いっても、別の人には読みにくくて、センスの悪いものに見えるこ
ともある。仕事では、クライアントに折れて、改良ならぬ「改悪」
をしてしまったこともある。
書体設計というのは専門職だから、参考書も少ない。
明朝体を明朝体らしく、ゴシック体をゴシック体らしく描くため
の、いわゆるレタリングの参考書は、どこの書店でも入手できるが、
書体を設計する時に役立つものは、限られる。
桑山弥三郎著『レタリングデザイン』や、モリサワの『たて組ヨ
コ組』の初期の号ぐらいだろうか。
あとは、経験から学ぶか、既存の書体から規則性を読み取るかし
かない。
美術学校等でタイポグラフィ専門のところに入る手もあるが、や
ろうと思ったときに、自分の年齢がちょうど良いかどうかの問題が
ある。
そんな中で、恐らく唯一、ビットマップフォント設計のノウハウ
が、具体的に述べられている参考書が、これだ。
無論、タイプフェイスについても、得るところが多い。
『書体を創る』〜林隆男タイプフェイス論集
林隆男著／ジャストシステム
ISBN4-88309-431-6 C3070 定価1800(1748)円
私は数年前、この草稿の一部を林氏からいただいた。
既に経験から分かっていたことも多かったが、全く気づかなかっ
たこともいくつかあり、不勉強を思い知らされた。勉強といっても、
誰かに師事する以外に、方法がなさそうだけど…。
尚、ビットマップフォントの組版については、次回以降に述べる。
【付録】超否定的でゴメン
●わが家にもMac OS 8がやってきた。
マシンは、春にMac II ciから、Power Mac 7600/200に買い換え
たので、パワーは十分である。
まだ重いアプリはあるが、FontoGrapherでバックに画像を貼り込
み、拡大率最大で複雑なフォントを編集しても、全く速度低下がな
いのだから、驚かされる。
Finderでイライラすることも、ほとんどない。Mac II ciで、漢字
Talk 6.0.7を使うよりも快適である（当たり前だが…）。
だから、何の躊躇もなく、Mac OS 8をインストールした。
ところが、Finderが遅〜いのである。１、２年前のマシンでは、
どうなるのかと、心配なほど遅い。短い待ち時間でも、マウスカー
ソルが「時計」になるのは、心理的に逆効果ではないか？
Mac II ciが、ミッドレンジからローエンドに転落したのは、クア
ドラやセントリスの登場もさることながら、漢字Talk7の遅さに理由
があったように思う。そして、今度のMac OS 8も、多くの中堅マシ
ンをストレス満載の旧型に変えてしまうだろう。
このような批判は不毛だと分かっているが、なぜ、これほど重く
なるほど機能を詰め込むのか？ 現在使われている主要マシンを想
定してOSを設計するなら、もう少し軽くした方が快適なのではない
か。
とりあえず、私は古いシステムに戻したが、再びMac OS 8に乗り
換えるかどうか、迷っている。機能的には、やはり魅力がある。と
はいえ、買ったばかりのこのマシン。強化する手段も限られるし、
金もかかる。
Mac特有の問題とは、新しいマシンでは古いシステムが動かない
ことだ。今後発売されるMac OS 8マシンのローエンド機（PowerPC
603eマシン）が思いやられる。
●日本語FEPの高機能化が進んでいる。日常的な文章を効率よく、
なるべく一発で変換できるというのは、確かに重要な要素だと思う。
しかし、多くのFEPでは、第２水準漢字の辞書が弱い。日常的な
漢字の旧字体が、訓は勿論、音ですら登録されていない。
コード入力の他に、部首別画数別変換もあるが、目的の漢字がど
の部首に属するのか、判断は難しい。
日常の文章が素早く入力できても、たった１文字の第２水準漢字
を探すのに１０分も２０分もかかってしまうのでは、変換効率が良
いのか悪いのか、分からない。
一部のFEPにある「総画引き」は総てのFEPに欲しい。部首に関
係なく、漢字の構成部品から変換できる機能と、新字体・旧字体の
相互変換。総ての漢字について、音読み、訓読みの登録。
構成部品変換辞書の作成は容易ではないが、その他は少ない労力
で実現できる。
それらを組み合わせ、例えば、総画で「１４画」の漢字を指定し、
候補数が多かったら（多いに決まってる）、さらに絞り込むように、
「口」の入った漢字のみ洗い出す。それでも、目的の漢字を見つけ
るには候補が多かったら、その中でさらに「山」を含む漢字、とい
うような、多段階の変換ができれば、いい。
読みが分かっていても「し」とか「せい」なんか、候補数が多す
ぎて目的の漢字が見つけにくい。あ〜、絞り込み変換さえあればな
ぁ。って、ほとんどのFEPの辞書じゃ大した候補数じゃないか…。
こういうの、日本語文章の意味解析に比べれば、よほど簡単で効
率的じゃないかな。
実は、私はX68030の日本語FEPにほぼ満足している。
マシンが古いのだから、このFEPも当然古い。しかし、辞書がフ
リーウェアの「AI辞書」というものなのだ。
この辞書。ファイルはメイン辞書とユーザー辞書にフル登録（も
うほとんど登録できない…）で、１Ｍバイトちょっと。辞書ファイ
ルのサイズは、このFEPで扱える限界なのだそうだ。
意味解析なんてないから、「貴社の記者が汽車で帰社した」等は
一発変換できない。学習機能も貧弱だ。
ところが、こいつには第２水準漢字が残らず「音」で登録されて
おり、旧字体も新字体同様に変換してくれるのだっ！！
たったそれだけのことで、快適な日本語入力環境が実現する。
どんな文章を打つかによって、快適さに要求されるものは違って
くるから、第２水準漢字や旧字体は使わない人には、意味がないか
も知れないが…。
●メニューバーに代わって、円形メニューが注目されている。
丸いメニューの中に、放射状に項目を配置したものだが、人間は
距離よりも角度を記憶しやすいことに基づいているという。
メニューバーより、ミスが少なく目的の項目をクリックできるら
しいが、メニューバーや、アプリのツールボックス等が、画面の上
端、右端、左端等、画面の端に配置されていることを、忘れていな
いだろうか。
ある程度熟練したユーザーや、１７インチ以上のディスプレイの
ユーザーは、マウスカーソルの動きを速めに設定し、マウスを持ち
上げずに、マウスカーソルを画面の端から端まで移動できるように
していると思う。
速く動かせると、微妙な位置に瞬時にマウスカーソルを移動させ
るのが難しくなる。だから、メニューバーを使うには、まず、一気
に（必要以上に）マウスを上に移動させ、そこから、マウスを左右
に動かして、目的の位置に持っていくことになる。
円形メニューは、メニュー内に入ってからの操作性は高いかも知
れないが、メニューに入るまでに微妙な操作を要求される。
メニューバーなら、マウスをパッと上に動かし、後は左右の座標
を合わせるだけでいい。項目をドラッグしたら、今度は縦の動きだ
けだ。深い階層のメニューも、そこからマウスを右に動かし、次は
上下の動きだけ。
初心者にとって、マウスカーソルのX座標とY座標を同時に合わせ
るのは、難しい。
誰しも、マウスカーソルを上に動かしたいのに、斜め右上に動い
てしまう、というような経験を持っているだろう。
指やペンなどで、画面上のメニューをタッチするタイプのマシン
では、威力を発揮しそうだが…。
第５回●似ているって、なんだろう？ 1997. 10. 13(月)
誰かに似ているというだけで、親しみが沸いてくることがある。
私には、人を見ていると、誰に似ているかな、と考えてしまうク
セがある。
最近は、反町隆史と岩城滉一が似ているという、隠し子疑惑なん
てのもあったな〜。
誰も言っていないところでは、小林千絵って、フジテレビのアナ
ウンサー小島奈津子に似ていると思う。
雰囲気は似ていないけど、顔のつくりが似ていると思うのが、八
木亜希子と牧瀬里穂。以前は全く違っていたのに、なんかお互いに
だんだん似てきた気がする。
武田祐子は、元CoCoの大野幹代だな。年は武田アナの方が少々上
だけど背の高さも同じくらいだし。
（富永改め）冨永美樹は、吉本の山田花子にちょっと似ている。と
いうと、ファンに怒られるかな。
以前、フジの土曜だったか、ゴールデンに『BAN! BAN! BAN!』
って番組があった。司会のシルビアの正体とは、同局のアナウンサ
ー近藤サトのガイジン風メイクだったという噂もあったとか、無か
ったとか（無かったが正解）。
元フジテレビの有賀さつきは、日色ともゑだろうな。年はずいぶ
ん違うけど…。
日本テレビに移って、魚住りえは藤圭子。町亜聖は五十嵐いづみ
というところか。人じゃないけど、山王丸和恵って、こけしに似て
いると思う。顔と髪型と体型が…。
ローカルネタで申し訳ないが、福井テレビの鈴木理香と、テレビ
朝日の丸川珠代って、似ている。
アナウンサーから離れてみると、原千晶って、若い頃の岡崎由紀
だよな。立河宣子と鮎川いずみってのもありかな。榎本加奈子と鳥
越まりも結構似ていると思う。顔も性格も体形も（鳥越まりの方が
かなり背が高い）。
今は全然似てないけど、デビュー当時の水野美紀（真紀ではない）
と加藤紀子って、結構似ていた。
ココリコ遠藤は、巨人の元木に似ていると言われるが、鳥羽潤に
も似ていると思う。
前置きが長くなったけど、写研の「ゴナ」と、モリサワの「新ゴ」
が似ているせいで、両社が争っているのは、周知の通りだ。
同じ明朝体、ゴシック体で、ウェイトも同じ書体同士の場合、特
徴は、仮名のデザインに表れる。
言い換えれば、漢字だけ並べてみても、ほとんど区別がつかない
わけで、一方の書体の漢字をコピーして、細部に若干の加工を施し
て盗用するということは、理屈上は簡単な話である。
いくら、仮名のデザインが、書体の表情を決める重要な要素だと
いっても、7000字近い漢字を作成する労力には比べるべくもない。
「新ゴ」と「ゴナ」の仮名だけを比べてみれば、その違いは明らか
だし、また、発表時期の近さから、前述のような方法で漢字デザイ
ンの盗用があった可能性も、ほとんど考えられない。
これは結局、決着のつかない話だろう。
ナールやゴナの仮名の骨格って、タイポスの影響を強く受けてい
ると思う。「たな」とか、濁点、半濁点の位置なんかは違うけど、
タイポスが無ければ、もっと違った、もっと古いタイプの書き文字
に近い骨格になったのではなかろうか。
そう思うと、ゴナは新ゴよりタイポスとの類似について、クレー
ムをつけられるべきかも知れない。
私は主に、低級数のビットマップフォントを制作してきたが、12
ドットや16ドットでは、漢字の「一」、マイナス記号、プラス記号、
一部の英数字など、既存のフォントと全く同じビットマップパター
ンにならざるを得ない場合が出てくる。
世界中には、多数のビットマップフォントがあるだろうし、誰が
先に制作したかも定かでない。消去法でパターンを変えていったと
ころで、バリエーションが２、３通りしか考えられない文字もある
のだ。
書体なのだから、組んだときの全体の印象で、似ているか否かが
決まるのだし、一文字一文字が似ているかどうかを、論議しても不
毛だと思う。と、言い訳しておこう。
そうだ。
松島菜々子も、最近顔が変わって、水野真紀（美紀ではない）に
似てきた。『綺麗なお姉さん』のCMに、松島菜々子が出ているの
を見て、これじゃ前と同じじゃないか、と思った。
似ているってのも、良し悪しだな。
（以上敬称略）。
※第３回『角田久美子のタイポグラフィ』補足
東京都新宿区に「角筈」（つのはず）という地名があるそうだ。
この角筈の「角」が、角田久美子さんの「角」と同じ、中央の縦
線が、下に突き抜ける字体だという。
ある人が実際にそこで調査したところ、看板等では総て普通の
「角」が使われており、唯一、手書きの看板に「角」の異字体を発
見しただけであった。
写植に用意されていない字体ならではの、エピソードといえるだ
ろう。
私の地元福井県の鯖江市で、世界体操が行われた時、鯖江市内の
道路標識等に、「鯖」の字体が４通りも混在しており、どの字体に
統一すべきか論議されたのを思い出す。「魚」の下の分が「大」に
なったものと、「青」の下が「月」と「円」の者の違いである。
地名や人名を正しく表記するための、異字体の規格化のはずが、
地元でも結論がでないことがあるのでは、困ったものだ。
よく言われる「森鴎外」の「鴎」にしても、「区」に鳥の字体を
森鴎外本人が使用していたというから、あながち間違えとは言い切
れない。
第４回●TrueTypeは信用できるのか？ 1997. 10. 6(月)
もう５年以上前の話である。
Macがまだ「漢字Talk 6.0.7」の時代。私は「日本語ATM」を使
っていた。当時、安価な明朝体とゴシック体のパッケージには、
「漢字TrueType」と「日本語ATM」があったが、モリサワのリュ
ウミンライトのために後者を選んだのだった。
あの厄介なプロテクトの話は、他でさんざん論議されているので、
ここでは書かない。
まもなく、「漢字Talk 7」（通称：おにぎり(笑)）がリリースされ、
愛用のリュウミンライトも、TrueTypeフォントとしてシステムに付
属していた。
なにせマシンはMac IIci。RAM 8M、HDD 240Mである。ラスタラ
イズ速度やメモリ効率等が改善されるかも知れないと、同じリュウ
ミンライトをインストールしてみた。
パフォーマンスには、これといった変化が見られなかった。
しかし、私には、この新しいリュウミンがどうも、しっくりこな
かったのである。
プリンタは、キヤノンのバブルジェットBJ-10v。360dpiで若干に
じみもある安価な機種である。
印字してみると、どうも「はほよねぬ」等のむすびの部分のカー
ブが急で、線の太さの起伏が激しいように感じた。
ラスタライザのクセによって、同じフォントデータでも、若干の
違いが出てくるのだろう。ATMは、PostSriptフォントを画面表示
に使用するためのプログラムで、フォントのアウトラインデータは、
「ベジェ曲線」。一方のTrueTypeフォントは確か「3次スプライン
曲線」である。これらの曲線は、数学的に完全に相互変換可能だと
いう。
以上が、４、５年前に、NiftyServeのFDTPや、DTP関連のPATIO
で話したことの概要である。
そして、数年…。半年ほど前のことだった。
私は、FontoGrapherを愛用している。アウトラインフォントを
つくるには、他に選択肢が無いというほど、スタンダードなソフト
ウェアである。
これを使っている方は、ご存じだろう。既存のフォントを読み込
んでみると、PostScriptフォントに比べ、TrueTypeは２倍ほど多く
ポイントが現れる。これを加工して、TrueTypeフォントを作成しよ
うとすると、恐ろしいことに、フリーズしたりする。点がさらに２
倍に増えてしまうのだろうか？？
主にTrueTypeを使用しているユーザーには、困った事態だが、
「TrueTypeフォントも作成可能な、PostScriptフォントエディタ」
だと割り切ることである。
ところが、私が半年前に安く手に入れたEPSON MJ-800Cという
インクジェットプリンタのMac版ドライバには、色々と不具合があ
って、モノクロ720dpiで印字しようとすると、文字が二重にダブっ
て印字されるというトラブルに見舞われたのだ。
そこで、制作中のフォントを、Windows用のTrueTypeにして、
古いIBM PC-AT互換機のWindows 3.1Jから印字してみようという
ことになった。
確かに綺麗な720dpiではあるが、線の太さが太すぎたり細すぎた
りして、書体の表情が変わってしまったのである。
結論から言おう。
『FontoGrapherで作成されたTrueTypeフォントデータは、編集画
面のポイントや、曲線のカーブを、忠実に再現していない！！』
TrueType(Mac用でも同じ)を作成して、FontoGrapherでそのフォ
ントを読み込んで、各文字の編集画面を表示させてみよう。
そして、オリジナルのFontoGrapherのフォントファイルを開い
て、同じ文字の編集画面から、フォントデータをコピーし、ペース
トしてみれば、違いは一目瞭然である。
最近私は、メンテナンスしやすいように、ポイントの数を最小限
に抑えるようにしているので、長い制御線を多用した文字では、
TrueTypeでのギャップが、使用に耐えないほど大きくなったのであ
る。
尚、PostScriptフォントを作成した場合は、上記のような不具合
は全くない。作成したPostScriptフォントを開いても、ポイントの
座標や制御線、カーブの形状等に、一切の変質はない。
そこで、ふと５年前のリュウミンの違和感を思い出した。
あの違いは、ラスタライザのクセなどではなく、フォントデータ
そのものが、TrueTypeにコンバートした時点で、変質してしまった
のではないか？ そんな疑問がわいてきた。
とはいっても、モリサワのフォントはATM版、TrueType版とも、
プロテクトがかかっていて、アウトライン抽出ができないため、そ
れを確かめる手段はない…。
Windowsでは勿論、MacでもDisplay PostScriptの話より、True
Typeの拡張の方が、優勢のようだし、フォントをつくる側としては、
一抹の不安が残る。
デザイナーは、1000×1000ポイント（メッシュ）の編集画面でも、
1ポイント単位で座標を調節する。あの程度は誤差の範囲と言われて
しまっては、苦労のしがいがない。
ドローソフトで描いたものが、変質して表示、印刷されたとした
ら、イラストレーターたちは納得するであろうか。
バックナンバー目次に戻る
メニューに戻る