「縦書き専用フォント」という点に違和感

そのあたりというのは以下サイトであったりまとめであったり。

ソニーReader、縦書フォント使ってない疑惑。このでこぼこ感w【Twitpic/tmichiaki】
ソニーのReaderは、縦書き専用じゃないフォントが使われています。【株式日記と経済展望】
ソニーの Reader は、縦書き専用じゃないフォントが使われています。縦に並んだ各文字のセンターが合ってなくてガタガタなのです。【Report 3】
ソニーリーダーの縦書きがガタガタな件について【Togetter】

最後のTogetter内の一部で言及されてることではありますが、まさに『「縦組みには縦書き専用フォントを使わないとおかしい」という、非常に妙なことを誰が言い出したんだろう？』と。

ということで、以下いくつかに分けてそれを暴いてみるような真似事をしてみようと。ただしReaderが手元にないのはおろか、XMDFを作る環境すらないので、あくまでも手元にあるDTP環境（今回はIllustrator）とフォントを利用した比較を行いつつ話をしてみます。

そのいち。
まず今回のは「少なくとも縦組み字形を利用しているのは間違いないだろう」というところから。
これは見れば明白なんです。この時点で最初の話がかみ合わない。証拠は以下の画像。

ということで、「縦組みの際にグリフが変わる文字」として、幼音・促音・音引きを比較。Readerに対し、MS明朝の横・縦それぞれを出したところです。
幼音・促音はちょっとわかりづらいですが、和文字形の仮想ボディ基準からして、比較的右寄りになってます。そして音引き、これは筆づかいの流れによって把握でき、Readerも縦組み字形としての「筆始めのおさえ向きが左である」ことが（画像ではわかりづらいですが）把握ができる。横組みを90度廻してもこうはならない。あるとしたらさらに左右反転させる手法はあるんですが、この文字のためだけにそれをやるのかどうか。
句読点などを含めたとしても、横組みのフォントを内部で無理矢理縦組みにする、なんてことはしてないはず。そんな処理、フォント側を修正するよりも面倒です。

そのに。
欧文用のレイアウトエンジンを持ってきているからでは、という話。それもちょっと考えにくいのではないかと……気持ちはわからんでもないですが。
欧文用のエンジン、ということだと、おそらく「ベースライン基準で表示させる」ということだと思うんですが、考え得る結果を以下例で。

一番左はオリジナル。左右にぶれまくってます。
比較例ではかなプロポーショナルとしてありふれたフォント、MS P 明朝を使ってみたり。
(A)横組み字形をベースラインで組んだことを想定したもの、すべて左に寄ります。
(B)横組み字形をセンターに揃えて組んだもの。
(C)縦組み字形で組んだもの。かなの字間がフォント側の情報に依存するので仮想ボディに揃いません。
比較すると、Readerの結果は(A)～(C)いずれにも一致しない。比較的似てるのは(B)のセンターだったりするわけで。

(A)はなんでこんな風になるのかというと「デジタルフォントはすべて欧文ベースライン基準の構造ありきなので、プロポーショナル字形も欧文記述方向を前提の構造になっている」という所以。

上記の画像は、HG P ゴシックE（MS-Office 2003付属）を、TTEditで開いたもの。「あ」と「く」ですが、それぞれ幅が違う、かなプロポーショナルなフォントですが、この字形の発生基準は左端。欧文字形と同じです。字形ごとに幅が違う結果として、プロポーショナルとして並べられるのがこのテのフォントの特徴。このような横組み字形を1文字ずつ縦で並べたうえで、さらに組処理では欧文ベースライン的に並べれば、(A)のようになります。
ただ、(B)のようにセンターに揃えてしまえば多くの和文字形が持つ中心の重心を基準で目視できるので、あまり違和感なく読むことも可能です。
その(A)(B)を普通のプロポーショナルではないフォント（かなも等幅のもの）に当てはめた場合、発生基準こそ左端という点は変わらないですが、通常の和文フォントは仮想ボディを正方形に見立てて作成しています。よって、縦・横いずれでもベースライン・センターなどいずれの基準で揃えて並べたとしても、同じ文字サイズ（仮想ボディサイズ）を指示している限りは揃えの結果はいずれでも変わることはない、ということです。結果、一部の文字を除いては縦・横同じ字形を利用することができる。

なお(C)が正方形に揃わないのは、かなも縦組用字形に置き換わっているため。かなプロポーショナルの場合は同じように見えるグリフであっても、縦・横それぞれで別のグリフコードを持たせ、異なる字形にすげ替えてます。字形としては上端が基準になって幅がそれぞれ異なる。横組みを右90度回転させた状態を基準に作り出してます。これもデジタルフォントの構造所以から来るもの。
ただし漢字は縦・横それぞれ共通のグリフを利用しています。これは仮想ボディが正方形基準になっているため。ごく一部の例外を除いては、通常、大半の字形は縦・横共通で使われるのが和文フォントの特徴のひとつでもあるわけですから。

いずれにしても、横組み用フォント（字形）でもなさそうだし、欧文ベースライン基準で組んであるからとも言い難い可能性が高い。もちろん推測でしかないので断定も難しいところですが、上記意見内の断定も困難だろう、と。あと普通に考えると、わざわざ従来基準を崩してまで作ることもしないのではないか、というのもあります。むしろそのほうがよっぽど面倒だろうに……。

そして、そのさん。 SONYの製品サイトとかPC Watchにあった縦組みサンプルの状態を見る限りは、これらで縦組みのバランスが酷く悪いかというと、あまりそうは見えない。今回のように左右にブレている点も見受けられない。
なので推測ですが、考えられるとしたら以下のいずれかかなと。

• （togetterで言及されているように）個々のデータの作り方に問題がある
• Readerには複数のフォントが搭載されており、一部のフォントの重心バランスがおかしい

1番目、これは自分がXMDFというフォーマットについて把握できないのでアレですが、作り方をミスったらこうなるかもしれない、という可能性はゼロではないかもしれない。確かに制作段階でなぜ気づかなかったのか、という指摘はあながち間違ってないように思えてしまいます。もっとも「なんでもいいからリリースに間に合わせるためにデータを作る」のが目的になっているとしたら、確認なんかしていなくて当然かも知れませんが。
2番目。Reader内には複数のフォントが用意されていて、実はデータから切り替えて利用することができるとした場合。その中にバランスがよろしくないフォントがあり、それが選ばれて表示された結果としておかしくなっているのでは、という。縦横での組処理にあわせてバランスを整えていない、ひとつひとつの文字（グリフ）の重心が安定していないだけのフォントっていうのはかなり簡単に作ることはできるので。粗悪品ともいいますが。

まあ、1番でも2番でも別の理由でもなんでもいいんですが、いずれにしてもこういうのを見せられる限り、電子書籍にまだまだ未来は見えなかったりします、個人的に。というかどのプラットフォームであろうが、どれもこれもプラス面よりもマイナス面が優った状態でしか見えてこないのはどうなんだろうか。10年くらい待てばもっとよくなるのかなあ、うーん。

#そもそも、実機を見ずに考察していること自体が問題、だと言われるとおしまい、かもしれない。まさに自爆。
ちなみに縦書き専用フォントがないわけじゃないですが、現在の汎用デジタルフォントとしては希です。といっても写植の頃などでも当然とは言い難い面もありましたが。

---

■2010.12.14追加＆修正

【1】togetterのほうで今回の問題が起きる原因っぽいTweetが追加されてました。こちら。……もしそうだとしたらある意味アナログチックな動きをするなあ、と。バグでしょうけれども、ちょっと面白い。

【2】Readerに搭載のフォントはイワタ明朝体の新がなとのことです。（情報提供：NAOIさん。関連情報その１・その２・その３）。としたら、フォント自身の素性は非常に良いものです。上記とあわせると「Reader本体の問題の模様」と推察できます。なので打ち消し線入れまくり。