hirax.net::Keywords::「選択肢」のブログ

■柿ピーのシーソー・ゲーム　

柿とピーナツの供給バランスを考える

　結婚しようとするカップルが少しばかり気にした方がよいのが、「柿ピーの好み」である。知らない人がいるとは思えないが、念のために書いておこう。柿ピーと言えば、柿ピー= 柿の種 + ピーナッツであって、亀田製菓の大ヒット商品である。そして、何と言ってもビールの安上がりのおつまみだ。
 

いわゆるひとつの「柿ピー」

　この「安上がりで手軽なおつまみ」というところが、結婚しようとするカップルにはとても重要である。何故なら、結婚する前のカップルであれば洒落た店で飲むことも多いかもしれないが、結婚後はなかなかそうはいかない。いつの間にか手に持ったワイングラスは缶ビール（しかも発泡酒）に変〜身し、「テーブルの上の豪華な食事」はちゃぶ台の上の亀田製菓の柿ピーにバケラッタしているのである。

　そうなると、かつては「このソースとても美味しいよね。うふっ。」なんて言っていた二人も変わらざるをえない。そりゃそうだ。柿ピーを目の前にして、気取ってみてもしょうがないわけだ。そんな時、こんな会話に走りがちである。

「柿の種ばっか、食べないでよ！」
「オマエこそ、ピーナッツどんどん食えよ！」

　これが、カップルの二人がとても似たもの同士で、「私達二人とも柿の種がスゴ〜ク好きだから、ピーナッツなんかいらないの。だから、- 柿の種だけが100%入った柿の種 - を買うの！」なんて感じなら、もちろんノープロブレムだろうし、あるいは、「ぼくらは、ピーナッツだけを買うのさ！」という感じのカップルでも同様だろう。
 

そんな二人のための「柿の種だけが100%入った柿の種」

　あるいは、もう「ぼくは柿の種が好きだけど、きみはピーナッツが好き。二人は違っているから良い組み合わせなのさ。柿の種はぼくがどんどん食べるから、君はピーナッツをお食べ」なんてカップルでもいいだろう。こちらも、「ひとまずは」ノープロブレムである。つまりは、全く同じが正反対のカップルであれば、大抵の場合ほとんど問題はないのである。

　しかし、「柿ピーは柿の種とピーナッツが適当な割合で入っているから良いのさ」なんていうグルメ気取りのカップルがいたりすると、大変である。

「アンタの食べる割合、少しおかしくない？」
「何言ってんだよ！オマエの方が柿ピー食べ過ぎだってんだよ！」
「そんなことないわよ！」

　そして、しかもこれが理系カップルともなれば、もう最低だ。

「柿とピーの割合は7:3で食べなさいよ！」
「違うだろ、6:4が適正値に決まってるだろ！」
「そんなにピーナッツを食べたいなら、柿ピーじゃなくてピー柿＊にしなさいよ！」
「別にピーナッツが過半数を超えるほどがイイって言ってんじゃねぇ〜！」
「何よ、もっと定量的に話しなさいよ！」

　そういうわけで、「柿ピーの好み」「柿ピーの割合」「柿ピーの消費の割合」なんていうものは、結構結婚しようとするカップルには重要なのである。結婚しようとするカップルはぜひとも心して聞いておいてもらいたい。とはいえ、モテモテ度テストで

「女にモテない、というより、女に興味がないオマエ。今、一番気になることがドリキャスの値下げだったりなんかしない？　まーそれも人生だけど、モテたほうがおいしいことは多いぜ？　もうちょい女に関心持てよ。」

　ところで、そもそも柿ピーの割合はどのくらいが普通なのだろうか？WEBで検索してみると、柿ピー10に対して

• 柿の種 : 7〜6
• ピーナッツ : 3〜4

　そこで、試しに私も手元にあった小袋入り亀田の柿ピーの中身を調べてみた。調べたのは「小袋入り亀田の柿ピー」である。
 

小袋入り亀田の柿ピー

　この一袋の中身を開けてみると大体こんな感じである。
 

一袋に入っていた柿ピー

　もちろん、単に数えても良いわけではあるが、「クダラナイことに、無意味なほどに大ゲサな道具を使うのがこのサイトのポリシー」でもあったりするので、まずは画像処理ソフトを使って柿の種とピーナッツの個数をカウントしてみた。使ったソフトはUTHSCSAImageTool である。PCベースでフリーでお手軽で粒子カウントとなるとこのソフトになるだろう。もちろんNIH-imageベースのScionImagePCという選択肢もないわけではないが、こと粒子カウントになるとはるかにImageToolの方が使いやすい。マクロの取っつきやすさ（機能は較べものにならないほどおちるが）もNIH-image系よりも上である。

　さて、まずは上の画面内で柿の種を粒子カウントしてみたのが次の画面だ。この画面では見つかった柿の種は赤い縁取りがされ、個数がマーキングされていることがわかると思う。ちなみに、この画面内では93個の柿の種が見つかった。しつこいようだが、「数えた方が早いだろっ！」というツッコミはこの「できるかな?」では厳禁である。
 

柿の種は大体100個
ちなみにこの画面では93個

　同じようにして、ピーナッツをカウントしてみたのが次の画面である。この画面では、ピーナッツは23個見つかった。
 

ピーナッツは大体20個
ちなみにこの画面では23個だった

　すると、個数ベースでピーナッツが23/(93+23) = 20%で、残りが柿の種で80%ということになる。柿ピーの割合は大体8:2であったことになる。確か、WEBの亀田製菓に関する情報では

「柿ピー」のブレンドは、柿の種6に対してピーナッツ4が基本

　ところで、大きな袋に入った柿ピーを食べながらよく考えることがある。私は柿の種が大好きなので、柿の種ばっかり選んで食べていくと、袋の口近くの上の方にはピーナッツばかりが残り、明らかに袋の場所ごとに柿の種とピーナッツの割合が異なってしまっていることがよくある。この柿の種とピーナッツの割合の時間的・空間的変化は一体どうなっているものだろうか？そこで、今回その「ピーナッツの柿ピーに占める割合の時間・空間的変化」について、少し考えてみることにした。
 

　まずは簡単に判るように、袋の中から均等に柿の種とピーナッツを「柿ピーの割合を適当な割合で」食べていった場合、「ピーナッツの柿ピーに占める割合」は次の図のようになる。この図は横軸が時間で、縦軸がピーナッツの柿ピーに占める割合である。
 

ピーナッツの柿ピーに占める割合の時間的変化

青 : 柿ピーを8:2の割合で食べた場合 緑 : 柿ピーを8:3の割合で食べた場合

　今回の場合柿ピーは8:2で入っているので、青の場合のように柿ピーを8:2の割合で食べていくと、時間にして10分後に柿ピーがなくなるまで、ピーナッツの柿ピーに占める割合は20%をキープしたままである。しかし、（少しばかりピーナッツが好きな人が）柿ピーを8:3の割合で食べてしまうと、つまりピーナッツを過剰に食べてしまうと、どんどんピーナッツの割合は減ってしまい、ついに8分経過後にはピーナッツが袋の中から無くなってしまうのである。つまり、あとの２分は悲しみと共に柿の種を食べ続けなければならないのである（私は柿の種が好きなので悲しくもなんともないが）。

　じゃぁ、袋の中の空間的分布も考えてみたらどうなるか、というのを次に計算してみた。まずは、袋を大きく二つに分けて、袋の入り口で適当な割合で柿ピーを食べた後、袋の奥から袋の入り口の方へ柿ピーを持ってくる。また、その際に適度に柿ピーをかき混ぜる。そして、柿ピーがなくなるまで柿ピーの割合の変化を調べてみるのである。ちなみに、IE4以降+Excel2000以降？の人であれば、ここをクリックすれば、その計算シートで遊ぶことができると思う。

　例えば、「柿ピーを8:2の割合で食べた場合」と「柿ピーを8:5の割合で食べた場合」のピーナッツの柿ピーに占める割合の時間・空間的変化を調べてみたのが、次に示す結果である。ちなみに、このいずれも横軸は時間である。また、時間軸にして30前後の時点で柿ピーは完全になくなっている。
 

ピーナッツの柿ピーに占める割合の時間・空間的変化

左 : 柿ピーを8:2の割合で食べた場合　　　右 : 柿ピーを8:5の割合で食べた場合 ちょっと計算上の誤差が大きいが、それはちょっと無視してもらいたい。

　さて、左の「柿ピーを8:2の割合で食べた場合」、つまり本来の柿ピー比と同じ割合で食べていった場合には、入り口近くでも奥の方でも柿ピーの比率は変わらない。そして、入り口の方から柿ピーを取った分を、奥の方から補給しているので、奥の方では時間軸20の時点で空になってしまっている。左の図でピーナツの割合がゼロになっているように見えるのは、実は単に柿ピーがなくなっただけなのである。そして、入り口近くの柿ピーが時間軸30の時点で空になっているまで、柿ピーの比率は変わることはない。当たり前だ。

　では、「柿ピーを8:5の割合で食べた場合」はどうだろうか？つまり、本来の割合よりもピーナッツを多く食べがちな人の場合だ。そんな場合の右を見てみると、奥の方は単に入り口近くに柿ピーを補給しているだけなので、柿ピーの割合は変わらないままだ。しかし、入り口近くではあっという間にピーナッツの割合が減ってしまっている。ほとんどなくなっている、といっても良いくらいの状態である。つまり、ピーナッツ大好き人間にとっては、手の届く袋の入り口近くには全然ピーナッツがないという、拷問状態なのである。周りに女子校や共学の学校はあるけど、自分の通う学校が男子校だったみたいなキツイ状態である。ちなみに、私は高校時代に私服の共学の学校に通った結果、制服の女子高生に強い強い憧れを抱くに至ったことを否定できなかったりするのである。
 

　話を戻して、それでは「袋を適当にかき混ぜながら」、「柿ピーを8:5の割合で食べた場合」はどうなるだろうか？というのが次の結果である。こうすると、奥の方のピーナッツもどんどん消費されているのがわかる。入り口近くも奥の方も、同じようにどんどんピーナッツの割合がどんどん減ってしまい、時間軸15の時点で完全になくなってしまっている。あとは柿の種がなくなる時間軸30の時点まではもう柿の種と向かい合うだけの人生なのである。ツラすぎる（ピーナッツ好きの人にとっては）。私の知人のオッパイ星人が結婚後に妻から、

＊一部、不適当な発言がありましたことをお詫びします。
 

「袋を適当にかき混ぜながら」、「柿ピーを8:5の割合で食べた場合」

柿ピーの袋の奥の方でも入り口近くでもピーナッツがすぐになくなっていく

　つまりは、ピーナッツが食べたいからといって、あまり柿ピーの袋をかき混ぜるのは良くないということなのである。もちろん、短期的にはピーナッツがたくさん食べることができて良いわけであるが、長期的に見ればその後の長い「柿の種人生」が待っているのである。それが端的にわかるのが、次の「ピーナッツをどれだけ食べているか」を示す結果である。

　この結果の中で、上の方に示した「柿ピーの袋をかき混ぜない場合」では、結構最後までピーナッツを細々と食べていけることがわかるだろう。柿ピーがなくなるのが時間軸で30前後の時点であるが、その少し前23位の時点までピーナッツを食べていけるのである。それに対して、ピーナッツを早く食べたいばかりに、柿ピーの袋をかき混ぜまくりの下の「柿ピーの袋をかき混ぜた場合」には、時間軸で13前後の時点でもうピーナッツがなくなってしまっている。もう、コイツには「柿の種人生」しか残されていないのである。
 

　とはいえ、柿ピーの袋をかき混ぜながら太く短くピーナッツを食べるか、それをじっとガマンの子で細々と最後までピーナッツを食べるか、どっちが良いかは難しいところだ。ちなみに、私はかき混ぜまくりで柿の種を食いまくり、残ったピーナッツは人にプレゼントするというとても良い性格である。だったら、100%柿の種を買えって感じであるが、売店には置いてないことも多いから、しょうがないのである。
 

　というわけで、今回はビール（やっぱりあくまで発泡酒）を左手にそして柿ピーを右手でつまみながら、酔っぱらった頭で（いつものことだが）、ツマラナイことを考えてみた。モノが本当の柿の種であればオチて芽が出るのが普通なのだけれど、今回の柿ピーの話はオチがあるわけでも芽が出るわけでもない。酔っぱらいのタワゴトだから意味なんか全然ないのである。と、日記には書いておこう（意味不明）。
 

■ノートPC色々　

　東芝がPortegeを改悪（ワタシからすればね）し、PCカードスロットx2, 軽量、トラックポイント（3490のアキュポイントは最悪だが）という選択肢で選べるノートPCは消えてしまった。これから、一体どうしよう？
　松下はB5サイズXGA液晶搭載960gとトラックボール搭載B5ファイルサイズのLet'snoteとかちゃんとしてるが（バッテリー関係の故障は非常に多いが）、東芝は一体どうしてしまったのだろう？Lib20->Lib50->Portrge320->Portege7200->Portege3490ときた私はどうしたら、良いのだろう？困ったモノだ…。　そういえば、私の使ってる海外版Portege3490CT(つまりRAMがMAX256MBのヤツ)が新品16万円位で売ってた。欲しい人もいるのでは？（リンク）

■CleType自主学習（仮）　

ちょっと真面目にClearType（仮）

1. 楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド　-はじまり -　(2002.08.26)
2. 一本道か、分かれ道か　- ドキュメントの縦横比について- (2002.08.29)
3. 水平思考と垂直思考 - 文字の縦横解像度 -　(2002.08.29)
4. 細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密-　(2002.09.09)

楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド　-はじまり -　(2002.08.26)

　Lapvantageという楽しそうな会社を初めて知った。ノートPCをiMac風にするLapvantageDomeやPCを縦置きで使うためのLapvantagePortraitという、とても実用的でいて、それでいて明和電機のような面白い製品を作っている会社である。明和電機は兄弟が運営しているが、こちらのLapvantageの方はビアボーム親子がやっているらしい。iMac風スタンドの方は角度が振れないようのが（特にノートPCを立てられない）残念だが、Lapvantageの方はもう少しデザインがスマートであるならば今すぐにでも欲しくなる。
 

Lapvantage Products

Lapvantage Dome

Lapvantage Portrait

　複数の作業を切り替えながら作業をしたり、あるいはツールバーが多数出てくるようなソフトウェアを使って作業をする時には、左右に広いディスプレイが便利で使いやすい。しかし、単純に一つのドキュメントを読んだり、一つのドキュメントを書いたりする場合には上下に長いディスプレイを使うと、見通しがきいて考えをまとめやすくなる。気のせいか、頭の中の見通しがとても良くなるように感じたりする。だから、以前から横長の画面のノートPC(ToshibaPortege 320)を愛用していたりした私はノートPCの画面を横にして使ったり、縦にして使ったりと、画面を切り替えて使ってみたいと感じていた。AdobeAcrobat Readerであれば、画面を回転させて文章を読む機能があるので、これまでノートPCを回転させて電子ブックのようにして文章を読んだりすることもあった。　

　Lapvantage PortraitはPivotProのソフトウェア付きなので、Windowsの画面を自由自在に回転させることができる。だから、ノートPCを普通に横置きに使ってみたり、スタンドに載せて縦置きに切り替えて使ってみたり、と好きなように切り替えることができる。「これはなかなか便利そうだ」と思い、私も私も30日有効のPivotProのデモ版をインストールして使ってみることにした。

　そして、このソフトのインストールをきっかけにして

• ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)

• デバイスドライバーは仮免-ClearTypeの秘密 - (1999.09.26)

一本道か、分かれ道か　- ドキュメントの縦横比について- (2002.08.29)

　前回書いたように、複数のことを考えるなら「左右に長いディスプレイ」が良くて、一つのドキュメントを読むなら「上下に長いディスプレイ」が良い。その理由を端的に言えば、「目が左右についているから」だと思う。

　まず、「目が左右に付いているので、あまりに大きい左右への目の動きは、目にとってとても非対称な作業であるから不自然」だ。だから、左右を眺めるときには自然と頭を左右に振ることになる。その頭を左右に振るという作業は、頭の中での何らかの切り替え作業を伴うような気がする。だから逆に、ツールパレットの切り替えのような「何らかの作業の切り替え」を伴う作業であれば、その左右へ視線を移動する（自然と頭も左右に動かす）ということはとても自然な行為になる。しかし、それは一つのドキュメントを読むような場合には、いたって不自然な行為になってしまう。だから、一つのドキュメントというのは本来「上下に長い＝縦長」であるべきだと思う。

　そしてまた、「目が左右についているから」、人は上下方向を「一本道」に繋げて考える。例えば、絵画を眺めるとき、上に見える景色は多くの場合遠い景色で、下に見える景色は多くの場合近い景色だ。漱石の文学論の図を引くまでもなく、この「上下の遠さ、距離」というものを例えば時系列上の「一本道」に繋げるのは、いたって自然な連想だと思う。「遠い上」に見えるものは「遠い過去」で、下に来ればくるほど新しいことになる。それは、ドキュメントを読む場合に対応させて考えると、とても自然だ。それに対して、左右に並ぶものは決して「一本道」ではないのである。それは、「選択肢＝分かれ道」であって、決して一つの道ではないのである。左右に並ぶものは「複数の何か」なのである。

　だから、一つのドキュメントは上下に並び、上下に長いべきなのである。ドキュメントの表示も同じく、縦に長いべきなのである。
 

「文学の焦点」

漱石　「文学論」より

　最近のPCであると、ディスプレイは通常横に長い。だから、本来縦に長くあるべきドキュメントを眺めようとする場合には、表示を90°回転させてやることもある。そうすると、本の一ページのようにして画面表示を眺めることができる。例えば、AcrobatReaderで表示画面を回転させたり、PivotProなど使ってPCの画面表示自体を回転させてやれば良いわけである。
 

Acrobat Readerで90°回転表示をする

回転させない場合

回転させた場合

PDF表示を90%回転させている例

縦長のドキュメントを読むことができる

　このように、ドキュメント表示のための縦横比については、単にディスプレイの表示を90°回転させてやれば問題は解決する。しかし、表示のためのもうひとつの条件、表示品質が問題になってくる。そもそも、液晶(二十世紀においてきたCRTは無視しよう)の解像度はまだま低くて、それを改善するための技術としてClearTypeやCool Fontがあるのだけれど、AdobeのCool Typeはともかく、Clear Typeの場合には表示が90°回転しているという情報をClearTypeが取り扱わない（知らない）ために、上手く動かなくなってしまう。ClearTypeにしてもCool Fontにしても、液晶のRGBのカラーフィルターの並び方を利用してやることで解像度を高めているわけで、その並びの変化（表示の回転）に対応できない場合には表示品質を大幅に落とすことになってしまう。

　次に、「ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)」で考察した、文字の解像度についてもう少しちゃんと考えてみることにする。

水平思考と垂直思考 - 文字の縦横解像度 -　(2002.08.29)

　ドキュメントを表示させるためには、文字を表示させてやらなければならない。しかし、液晶ディスプレイの解像度は必要十分には高くないから、文字はつぶれてしまうことが多い。例えば、「現実問題春夏雪雹資本主義電計算機」なんて文字を表示させてみるとかなり潰れてしまい、非常に読みにくいのが判るはずである。これが、英語の"RealProblem seasons Snow capitalism Computer"なんて文字であれば、まだマシである。

　この日本語と英語の文字の解像度の差について考えてみる。比較例は下に示した、「漢字」と「英語」のテキストを用いることにする。
 

日本語と英語の文字の解像度

「漢字」

「英語」

　まずは、600dpiで20ptのMS Pゴシックのフォントを展開して上のような画像にした後に縦・横方向のそれぞれの解像度を考えてみる。ここでは、縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布を測ってみることにした(今回解析のために作成したソフトはここ（RunLength.lzh）においておく)。テキストのような二値の画像の「解像度特性」を計測するのであれば、このような解析にしなければならない。「ファイト！縦文字文化　-縦と横の解像度を考えよう - (2001.04.29)」でやったようなフーリエ解析は適切な方法ではないのである。

　下の図が縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布である。縦方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ横線の太さ（あるいは線の間隔）であり、横方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ縦線の太さ（あるいは線の間隔）ということになる。どれだけの細かさで「太さ」（あるいは「位置」）を描いてやらなければならないか、を示すグラフということになる。
 

600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合

「漢字」の場合

「アルファベット」の場合

　「漢字」の場合には「Vertical 方向で計測した線の太さ（あるいは線の間隔）、すなわち横線の太さ（あるいは線の間隔）」が「縦線の太さ（あるいは線の間隔）」に比べて、大きく小さい方にシフトしていることが判ると思う。また、横線の量が縦線の量に比べてずっと多いことも判ると思う。後者は「数字文字の画像学　-縦書きと横書きのバーコード - (2000.01.21) 」で考えたことと全く同じで、「日本語は横線が多い」ということを端的に示している。そして、前者は「Vertical方向で計測した（すなわち横）線の太さ（あるいは線の間隔）」が縦のそれより大幅に小さいということは、「漢字」の解像度は縦方向に大幅に解像度が高い、ということを示している。漢字は縦書き文字故に鉛直思考志向なのである。

　一方、「アルファベット」の場合には、これも「数字文字の画像学　-縦書きと横書きのバーコード - (2000.01.21) 」で考えたことであるが、縦線と横線の量においてはむしろ縦線の方が多いことが判る。水平方向に対して情報量が多いのである。アルファベットは水平思考志向なのである。「アルファベット」の情報量はそのかなりの部分が縦線によるものなのである。そしてまた、線の太さ（あるいは間隔）は横線の方が細い（あるいは線間隔が短い）が、その横線であっても「漢字」の縦線程度の解像度であることが判る。「漢字」に比べて「アルファベット」の解像度は低いのである。

　ただし、文字の解像度を「線の太さ（あるいは間隔）の最小値」だけで論じることはできない。「適切な線の太さ（あるいは間隔）」にすることができるほどに解像度が十分高いか、ということも重要である。もし、そうでなかったら線が妙に太くなったり、細くなったりしてしまったり、あるいは、線の間隔が妙に近づいたり離れてしまったり、つまりは文字のプロポーションが崩れてしまったりするだろう。上の場合は600dpiで文字を表示させた場合の解析例だが、次に現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみる。こうすることでことで「適切な線の太さ（あるいは間隔）」にできていない様子を確認してみたい。
 
 
 

細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密-　(2002.09.09)

　まずは、「現実問題春夏雪雹資本主義電計算機」という漢字と"RealProblem seasons Snow capitalism Computer"というアルファベットを現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみた。そして、前回と同じようにそのビットマップ画像の「縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布」を調べてみる。その結果が下のグラフである。また、前回に調べた、これよりも４倍程解像度が高い「600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合」をさらに下に比較用として示してみる。
 

150dpiの解像度で20ptの文字を出力してみた

「漢字」の場合

「アルファベット」の場合

600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合

「漢字」の場合

「アルファベット」の場合

　150dpiでTrueTypeをビットマップに量子化した場合には、漢字・アルファベットの場合共に、縦・横方向とも600dpi単位で4,8pixelの太さ＝150dpiで1,2ピクセル幅のパターンが発生していることが判る。このようなパターンは、600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合には見られなかったものである。つまり、、着目すべきは例えばアルファベットの場合、

• 縦方向には幅10pixel(600dpi単位)=2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
• 横方向には幅13pixel(600dpi単位)≒3pixel(150dpi単位)以下の高い周波数は存在していなかった

• 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が生じている

• 縦方向には幅7pixel(600dpi単位)≒2pixel(150dpi単位)以下の高い周波数は存在していなかった
• 横方向には幅11pixel(600dpi単位)≒2.5pixel(150dpi単位)以下の高い周波数は存在していなかった

• 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が非常に多く生じている

　また、これらの文字の場合には本来18〜15≒12pixel(600dpi単位)の線幅・線間のパターンが多いわけであるが、それを150dpi単位（　=600dpi単位で4pixel　)で量子化してしまうと、場所により4/12 = 33%もの線幅・線間の位置の誤差が生じてしまうことになる。不必要に狭い幅のパターンが作成されたり、不必要に広い幅のパターンが作成されたりして、これでは文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまい、見にくいことこのうえない。これはすべて、150dpiという低解像度で量子化してしまったためである。「低解像度の表示系の解像度に合わせて量子化（ビットマップ化）してしまうと、ますますその表示系では表示しづらい高周波のパターンが生成されてしまい、結果として読みづらい」という一見逆説的に思えてしまう（しかし当たり前の）現象が生じている。

　ところで、本題のClearTypeの場合には横方向（通常の液晶はRGBの3つのサブピクセルが横方向に並べられているから）の解像度を3倍だと仮想的に考えて、横方向を3倍の解像度で量子化を行うことになる。ここで、話の単純のために3倍≒4倍と思うことにすれば、つまりはClearTypeの場合には本来150dpiの解像度であるにも関わらず、サブピクセルを考えて600dpiの解像度で量子化している、ということである。それは結局上の二つのグラフの比較と同じであって、ClearTypeを使うと実は表示すべきパターンが「より表示しやすい低い周波数のパターン」になっているのである。それは、「文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまう」ことがなく、目にとってはとても見やすいパターンになるだろう。この量子化の段階について触れている情報は見たことがないが、実はこの量子化の段階にClearTypeの隠された（しかし、一番重要な）メリットがあるように思う。また、アルファベットの場合にはHorizontal方向に振幅を持つパターン（＝縦線）が支配的に多いため、Horizontal方向に仮想的に高解像度の量子化を行うことは非常にメリットを効果的に得られると考えるのが自然である。

　次に、このように量子化されたデータをClearTypeで表示する際の問題点・その解決方法について考えてみていくことにしたい。

　P.S.ちなみに解析ソフト（RunLength.lzh）をアップロードしました。
 

■去年見た「水面に映った景色」　

LIMG /diary_image/2003042701.jpg r /diary_image/2003042701s.jpg 　「モンゴルに行こうか、トルコに行こうか、それとも中国・メキシコ・タイの田舎に行こうか。とにかく日本を出て新しい世界に行きたい」という加奈陀人。彼女の手首を見せられたのは何時だっただろうか。
　彼女の状態は良くない、と見ていて思う。とても哀しいとは思う。けれど、何を選んでもその人自身の選択なんだろうとも私は思う。選択肢によっては、それはとても哀しいとは思うけれど。だけど、その人自身の選択なんだろうと、そういう人を見慣れてしまったせいなのかそう思ってる。

■ビル・アトキンソン氏講演　

　5月14日に大阪・扇町のMebic扇町で開催されたmACademia（まかでみあ）でのビル・アトキンソンの講演のようす。コンピュータ好きな人であれば、必読。

　「ダイアログの選択肢は当初"Cancel""Do It"だったが、"Do It"では"Dolt"（ドルト＝まぬけ）と間違われて、ユーザが怒ってしまうので"OK"になった」なんていう話も。