overprint

印刷とそれ以上の何かについて(少し電子書籍寄り)。気が向いただけでは更新されません。

縦書きテキストを美しくジャスティファイするために(Webkit調査編)

先の概論編の最後で、「テキストの領域(段落等)の行長を『文字サイズ×1行の文字数(字詰め数)』にします」と書きました。

では実際にやってみましょう。下記のようなテキストを作ってみます。


《html部分(p要素以外は各自で補足してください)》

<p id="test">あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもや ゆ よらりるれろわゐ ゑをん</p>

css部分》

p#test {
    writing-mode: vertical-rl;
    -webkit-writing-mode: vertical-rl;
    -epub-writing-mode: vertical-rl;
    padding: 0;
    background-color: #ffa; /* 範囲がわかるように背景色を指定 */
    font-size: 1em;
    height: 10em;
    text-align: justify;
}


これを縦書き対応webkit環境で表示させてみます。ここではLion 10.7のSafari5.1(7534.48.3)を使用しました(デフォルト設定で表示)。


「height: 10em」と指定したのに1行に9文字しかありません。最終行とそのひとつ前の行の字送りがずれているのがわかるでしょうか(空白文字のせいでわかりにくいかも)。text-align指定をコメントアウトして行頭揃えにしたものがこちら。


行末にかなりスペースがあるのがわかります。というわけで、現状webkit環境では、「テキストの領域(段落等)の行長を『文字サイズ×1行の文字数(字詰め数)』にし」ても意図通りには表示されません。

heightをどれくらい広げれば意図通りになるのか?

「height: 10em」で9文字しか入らないのなら、10.1emとかちょっと増やせばいいんじゃないの? なんて勘のいい方は気づくと思います。ではどれくらい増やせば10文字になるのか、つい勢いで徹底的に調べてみました。デフォルト状態のSafariで2文字の場合からheightの数字を少しずつ増やしていって、正しく表示された時点の設定を調べていきました。ついでにemだけでなく、デフォルト設定で1emと同じサイズの12ptの場合、16pxの場合もそれぞれの単位の指定で調べてみました。

それをまとめた表がこれです。

height指定一覧
文字数 height(em) height(pt) height(px)
2文字 2.061875em 24.7426pt 32.99px
3文字 3.061875em 36.7426pt 48.99px
4文字 4.061875em 48.7425pt 64.99px
5文字 5.061875em 60.7425pt 80.99px
6文字 6.061875em 72.7425pt 96.99px
7文字 7.061875em 84.7425pt 112.99px
8文字 8.061875em 96.7425pt 128.99px
9文字 9.124375em 109.4925pt 145.99px
10文字 10.124375em 121.4925pt 161.99px
15文字 15.124375em 181.4925pt 241.99px
16文字 16.124375em 193.4925pt 257.99px
17文字 17.124375em 205.4925pt 273.99px
18文字 18.186875em 218.2425pt 290.99px
19文字 19.186875em 230.2425pt 306.99px
20文字 20.186875em 242.2425pt 322.99px
26文字 26.186875em 314.2425pt 418.99px
27文字 27.249375em 326.9925pt 435.99px
35文字 35.249375em 422.9925pt 563.99px
36文字 36.311875em 435.7425pt 580.99px

emはfont-size:1emの場合、ptはfont-size:12ptの場合、pxはfont-size:16pxの場合です。


見てるだけでうんざりするくらい細かい数字です*1(つい勢いで調べてしまったけど、ふと我に返って軽く後悔…)。よく見ると1行あたりの文字数が9文字、18文字、27文字、36文字と9の倍数の時に誤差が少し大きくなっていくようです。内部処理がどうなっているのかはわかりませんが、何らかの処理が影響しているのかもしれません。

これをまとめると下記のようになります。

height計算式
文字数 font-size:1em font-size:12pt font-size:16px
2〜8文字 1em*文字数+0.061875em 12pt*文字数+0.7425pt*2 16px*文字数+0.99px
9〜17文字 1em*文字数+0.124375em 12pt*文字数+1.4925pt 16px*文字数+1.99px
18〜26文字 1em*文字数+0.186875em 12pt*文字数+2.2425pt 16px*文字数+2.99px
27〜35文字 1em*文字数+0.249375em 12pt*文字数+2.9925pt 16px*文字数+3.99px
36〜44文字? 1em*文字数+0.311875em 12pt*文字数+3.7425pt 16px*文字数+4.99px

さらに問題が…

状況が変われば現象も変わるようで、height:10emで9文字しか表示されていない場合でも、ブラウザの表示を拡大(cmd+「+」)もしくは縮小(cmd+「-」)すると時々正しく10文字表示される時があります。逆に、height:10.124375emを指定しても、ある拡大率では9文字しか表示されない場合もあります。

じゃあもう少し大きな数字を入れればいいかというと、そうなるとジャスティファイ指定した場合に文字間が空いてしまうようになります。それに、ざっとテストしてみたところ、どの拡大率でも意図通りの文字数を表示させるのはけっこう難しそうで、いずれかの倍率では文字ずれが起きていました。

じゃあどうすればいいの?

webkitが改善されていくのが理想ですが、どうなるかはわかりません。*3 逆に言えば、現状の問題を解決するために小手先のバッドノウハウを駆使して、将来webkitが改善されたために逆に表示がおかしくなるという可能性も考えられます。
まあとりあえずは、見た目の文字組みが違和感がない程度にheight指定の数値に余裕を持たせておくのが現実的な解決法だと思います。
こればかりは制作者がどの部分にどれだけこだわって手をかけるかによって対応が異なると思います。納得できる範囲で表示ずれを許容しつつ、こだわる部分にはこだわって制作するのがよいかと思います。ただ、読者の表示環境によっては、そのこだわりが読者に伝わらない可能性もあるわけですが。


「だいたいそこまで文字組みにこだわるのならPDFにすればいいじゃん」*4とここまでの長文を全否定するかのような意見で締めておきます。

*1:これ実際にはもっと細かいです。例えば10emの場合は10.12437499999999968025576890795491635799407958984375emになりました

*2:2文字と3文字の場合は誤差のせいか+0.7426ptになりました

*3:webkitInDesign並みの組版表現を再現できるようになることはないでしょうし、それで表示速度が遅くなっては意味がありませんから

*4:もちろんADPSでもいいですけど、あれは拡大縮小できないからなぁ…