プログラマの縦書きに対する思い
http://blog.goo.ne.jp/ikedanobuo/e/ab7a17b40d389dcd899691841c24261bより。
プログラマは縦書きには寛容だと思う。タケルンバ卿も小飼弾氏も縦書きはいいんじゃないのって言っている。自分も縦書きはいいんじゃないのって思う。
なぜか。
プログラマの元号に対する思い - プログラマーの脳みそやプログラマのハンコに対する思い - プログラマーの脳みそで取り上げた和暦やハンコは、プログラマにとっての日常であるプログラミングの際に目障りだから嫌いなのだ。縦書きはシステム開発とは割と縁遠いところにあるし、プログラマは普段は横書きの技術書を読むわけだが、読書量が多い人が多く縦書きの小説なども結構消化していたりするのでなじみ深い。
そんなわけで、縦書きには甘いんじゃないかな、と思う。
プログラムで縦書きをするのは難しくない
プログラムで縦書きをするのは難しくない。横書きをするプログラムと大差ない。ただし、現在のライブラリはほとんどが左横書き用に作られているので、縦書きしようとするとそうした資産が使えないことが多い。
プログラムで文字を書くというのは、文字の書かれたタイルを並べるようなものだと思ってもらえば良い。左上から右に向かってタイルを並べるのも、右上から下に向かってタイルを並べるのも、別に処理的にはなんら変わらないのだ。古典的には8x8の正方形といったタイルで文字を書いていた。ファミコンぐらいの時代をイメージしてくれるといいのだが、容量や解像度の関係で漢字はなしの時代だ。
現在のフォントというのはプロポーショナルフォントと呼ばれていて、正方形ではないタイルを並べるような感じになっている。この辺の面倒さはラテン文字のほうが数段上。
ラテン文字の面倒さ
欧米の活字は文字によって横幅が一定していない。iは狭く、wは広く印刷される。こうした植字の要求から横幅が一定しないフォントが出てきた。日本語の場合はあまり文字による幅の違い（縦書きで考えるから立て幅の違いと言うことになる）はないので、横書きならではの面倒な要求事項と言える。
以下はJavaのフォント描画を司る機能のドキュメントからの引用だが
アプリケーションが座標 (x, y) に文字を配置するように要求すると、文字はその参照ポイント (添付イメージでドットとして表示されている) がその位置に置かれるように配置されます。参照ポイントは、文字の「ベースライン」と呼ばれる水平ラインを指定します。通常の出力では、文字のベースラインの位置揃えをしてください。さらに、フォントのすべての文字は「アセント」、「ディセント」、および「有効幅」を持ちます。アセントは、ベースラインから文字の上端までの量のことです。ディセントは、ベースラインから文字の下端までの量のことです。有効幅は、AWT による次の文字の配置位置を示します。
文字配列または文字列も、アセント、ディセント、および有効幅を持つことができます。配列のアセントは、配列内の文字の最大アセントです。ディセントは配列内の文字の最大ディセントです。有効幅は、配列内の各文字の有効幅の合計です。有効 String は String のベースラインに沿った距離です。この距離は、String のセンタリングまたは、右揃えのために使用される幅です。
Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle
何を言っているのか分らないかもしれないが、つまり、ラテン文字を綺麗に表示しようという飽くなき努力がこの面倒臭いシステムを実装し、標準ライブラリを作りあげ、労せずに面倒なラテン文字表示を行えるようにしたということだ。*1
中学生の初期に横線が4本入った英語用のノートを使った覚えはないだろうか？あの下から2番目の赤色の線がベースラインという奴である。あれは、ラテン文字の小文字が下にはみ出すように描かれることから用意されている機能である。縦書きの日本語においては中心線にそろえるだけなので、そんな面倒な機能性は必要ない。
漢字の文字数
前世紀のコンピュータにとって、漢字の文字数の多さ、その画数の多さからくる要求解像度の高さは大きな問題であった。プレWindows時代に日本のコンピュータがNECのPC-9800シリーズに席巻され国民機とされたのは、その漢字を表示する機能があったからだ。*2Windows95ぐらいの時代になると、いわゆるDOS/Vがようやく日本市場に食い込み始める。これは漢字の表示の為のROMを搭載するのではなく、ソフトウェア的に漢字を表示できるようになったことが大きい。ハードの進化が大容量化が漢字の文字数に打ち勝ったと言えよう。
ところで、なんでPC-9800シリーズのような、国産のPCですら縦書き機能を持たなかったかと言えば、ラテン文字やアラビア数字との混用をする場合に横書きが便利であるという理由につきると思う。もっとも、欧米ですでに確立していたPC像を90度ひっくりかえしてまで縦書きPCを作ろうなどと云う酔狂な技術者はいなかったと思うし、いたとしてもPCが事務処理用だという需要を考えれば数字との混用のしやすい横書きを選択するのは妥当と言えよう。
ハングルはPC向きではなかった
言語学畑の人はハングルが好きな人が多い気がする。ハンコ・元号・縦書きをやめたくない歴史的な理由［絵文録ことのは］2008/12/17でもハングル絶賛だ。ハングルほど生まれの新しい、人工的な合理性で作られた文字は類を見ないからこそだろう。だが、そんなハングルはPCでのデジタル処理には甚だ不適切というか、まぁ処理しにくい文字なのである。
ハングルは字母の組み合わせで作られるため、組み合わさった結果の文字に対して文字コードを振るというのがやりにくい。機械的な組み合わせ11,172文字のうち、実際に使用されるのは1832文字と非常に不合理なのである。
古ハングルなどの表記などもできるように文字数を増やそうとしたらデータ的にスペースがなくてコードポイントを移動したのがUnicode 2.0でのハングルの大移動の話。
もっとも、ハングルのこうした難点も、現代の有り余るマシンパワーで富豪的にプログラミングして余裕で買わせるようになったわけで、欠点も目立たなくなったかもしれない。
縦書きに混在するラテン文字への対応
縦書きの文庫本などではラテン文字は90度回転して表記されることがある。これ、面倒なんじゃないのって話はあるだろうけど、そもそもフォントを縦書き用に用意するだけのことだからプログラム的には難しくはない。そう、縦書き用フォントさえあるのならば。
Unicodeには文字の方向を定めるためのコントロールコードが用意されている。*3LRE(Left-to-Right Embedding [U+202A])とかRLE(Right-to-Left Embedding [U+202B])がソレ。そんな面倒な問題も縦書きならあまり関係ない。
その他、面倒な文字とか
合字とは関わり合いになりたくない。複数の文字を組み合わせてひとつの文字を構成するようなやつ。最近タイ文字の合字を利用して眉毛を表現した顔文字が使われ出したが、アレが合字の一種である。*4
ライブラリが充実していてレンダリングしてくれるが、表示も面倒なら、文字列処理も面倒だ。プログラマ的には正直勘弁してほしい。
あとは半角カタカナとかも厄介。何が厄介ってユーザは半角カナと全角カナなんてのは表示幅の違いぐらいにしか思っていないから、「ｶﾀｶﾅ」で検索したら当然「カタカナ」をひっかけないといけないのだけど、文字コードてきには別物だから処理が面倒。シソーラスなんてやってらんない。日本が比較的早くにコンピュータを導入したから故の歴史的経緯で存在している文字だけど、プログラマ的には消えてなくなって欲しい文字。
なんか縦書きだからってコンピュータ処理が面倒ってわけじゃないって話だったはずが大分脇道にそれてしまった。愚痴っぽくなってきたのでこの辺でやめておこう。
*1:植字の話で言えば、fiって並んでいたらfの上の部分とiの点がくっつくような字体にしたいとか、そういうことをしてたりするわけでまぁ面倒くさい、面倒臭い
*2:漢字用のROMをハードとして搭載していた
*3:Windows | Official Site for Microsoft Windows 10 Home & Pro OS, laptops, PCs, tablets & moreあたりを参照
