テキストエディタのルビを縦書きで確かめるときは、「表示できた」という一度の印象ではなく、候補ごとに採用・保留・不採用を決められる票を作るのが安全です。この記事では、14組のruby／rt、writing-mode: vertical-rl、数字の12、記号の!?、句読点、行送りを同じ標本に入れ、静的なEPUB構造と実画面の見た目を分けて評価します。
今回確認済みなのはStage4の静的EPUB構造です。生成物のXHTMLとCSSを読み、rubyが14件、rtが14件で一対一に対応すること、縦書き指定としてwriting-mode: vertical-rlがあること、確認用文字列に12、!?、句読点が含まれることを確認しています。Rune Studioの実画面での字形、ルビの位置、記号の向き、行送りは観察していません。したがって、画面で崩れなかった、読みやすかった、行間が整ったとは断定しません。
Stage4で分かること、分からないこと
Stage4は、EPUBを展開して静的なファイル構造を調べる段階です。ここでは「必要な要素と指定が出力物に存在するか」を判定できます。一方、アプリのプレビューやEPUBリーダーがその指定をどの字形・位置・間隔で描くかは判定できません。
| 確認対象 | Stage4で確認したこと | Stage4だけでは未確認のこと |
|---|---|---|
| ルビ | XHTML内のruby 14件とrt 14件が一対一で対応 |
親文字と読みの実画面上の位置、欠け、重なり |
| 縦書き | CSSにwriting-mode: vertical-rlがある |
列が右から左へ自然に進むか、画面幅で切れないか |
| 数字 | 標本に12が残っている |
縦中横、回転、分離のどれで表示されるか |
| 記号 | 標本に!?が残っている |
向き、間隔、前後文字との高さ |
| 句読点 | 標本に読点と句点が残っている | 行頭禁則、ぶら下がり、字面上の位置 |
| 行送り | 前後比較用の行がXHTMLにある | ルビ行だけ広がるか、隣接行と接触するか |
この線引きを先に決めておくと、静的構造が正しいことを画面表示の成功へ言い換える誤りを防げます。Stage4の合格は「画面も合格」ではなく、「実画面で評価する候補を欠落なく用意できた」という意味です。
14組のruby／rtを候補表に固定する
標本には、天城／あまぎ、瑞穂／みずほ、紫苑／しおん、伊吹／いぶき、高嶺／たかね、千景／ちかげ、冬華／とうか、夏帆／かほ、夕暮／ゆうぐれ、木立／こだち、水面／みなも、灯火／ともしび、星／ほし、月／つきの14組を使います。
件数だけでは不十分です。rubyが14件、rtが14件でも、順番がずれたり、親文字と読みが入れ替わったりすれば採用できません。Stage4では各rubyの親文字と、その中のrtを順に照合し、14組が候補一覧と一対一で一致するところまでを合格条件にします。
実画面では、長い親文字、一文字の親文字、行頭、行中、句読点の直前を分けて見ます。グループルビは読みが親文字全体に対して不自然に片寄らないか、モノルビは一文字ごとの対応が途中で入れ替わらないかを確認します。ここは未観察なので、読者が現在版の画面で票を埋める項目です。
6項目の採否票
採否は「存在したから採用」ではなく、静的条件と目視条件の両方で決めます。用途によって望ましい組み方が違う12と!?は、自分の作品の組版方針も判定欄へ書いてください。
| 候補 | Stage4の証拠 | 読者が実画面で見る点 | 採用条件 | 保留・不採用条件 | 現在の票 |
|---|---|---|---|---|---|
14組のruby／rt |
14件対14件、一対一対応 | 親文字、読み、欠け、重なり | 14組すべてが意図した親文字のそばに読める形で出る | 1組でも欠落、対応違い、判読不能な重なりがある | 実画面未観察のため保留 |
writing-mode: vertical-rl |
CSS内に指定あり | 縦方向と右から左への列進行 | 作品の縦書き方針どおりに列が進む | 横書きになる、列順が意図と違う | 実画面未観察のため保留 |
12 |
XHTMLの標本内に存在 | 縦中横、回転、分離、周囲との高さ | 作品で決めた数字表現として読める | 二桁が離れる、向きが意図と違う、隣の文字と衝突する | 実画面未観察のため保留 |
!? |
XHTMLの標本内に存在 | 記号の向き、組み合わせ、前後間隔 | 感嘆と疑問の順が保たれ、判読できる | 順序が逆に見える、回転や間隔で意味を取りにくい | 実画面未観察のため保留 |
| 句読点 | 読点・句点を含む標本あり | 行頭、行末、ルビ直後の位置 | 句読点が欠けず、行頭禁則を含め意図した流れになる | 行頭へ不自然に孤立する、欠ける、ルビと重なる | 実画面未観察のため保留 |
| 行送り | 比較用の前後行が構造内に存在 | ルビ行と通常行の間隔、接触、極端な空き | 読みを追える間隔で前後行とのリズムが保たれる | ルビ行だけ広がる、読みが隣行へ接触する | 実画面未観察のため保留 |
現在の票がすべて保留なのは失敗ではありません。静的構造しか観察していない時点で、見た目の候補を採用へ進めないための記録です。
読者が現在版で票を完成させる手順
最初に、標本の本文と採否票を並べます。標本には14組のルビだけでなく、12、!?、読点、句点、ルビのない比較行も入れます。比較行がないと、行送りの差を判断できません。
次に、現在版の縦書きプレビューを原寸で見ます。画面全体の印象だけで決めず、採否票の上から一項目ずつ確認してください。最初は14組の対応、次に列方向、数字、記号、句読点、最後に行送りの順に見ると、原因を混同しにくくなります。
各項目には「採用」「保留」「不採用」のいずれかと、観察した場所を書きます。たとえば「月／つき、行頭で読みが欠けない」「12、二桁が一組で立つ」「ルビ行の後だけ間隔が広い」のように、再確認できる言葉にします。「きれい」「問題なし」だけでは、画面幅や原稿が変わったときに比較できません。
プレビューで採用できても、利用予定のEPUBリーダーでは別に確認します。アプリのプレビューとリーダーの描画は同じ証拠ではありません。Macの画面、書き出したEPUB、販売先の受理を一つの合格としてまとめず、環境ごとに票を分けると差を追えます。
Rune Studioについて記事で言える範囲
Rune Studioの現行Mac版には、縦書きプレビューとEPUB出力に関する公開説明があります。この記事の検証記録で言えるのは、Stage4の静的EPUB構造に14組のruby／rtとwriting-mode: vertical-rlがあり、標本に12、!?、句読点、行送り比較用の行があることです。
実画面の字形、ルビ位置、数字や記号の向き、句読点の位置、行送りは未観察です。販売先での受理、すべてのリーダーでの表示一致、実装中のiPad機能もこの記事の確認範囲には含めません。
結論：静的合格を、画面合格へ置き換えない
テキストエディタのルビを縦書きプレビューで確認するなら、先に候補と採否条件を固定します。Stage4では、14組のruby／rt、writing-mode: vertical-rl、12、!?、句読点、比較行という静的構造を確認できます。そこから先の字形、位置、向き、行送りは、読者が現在版の実画面で観察して票を完成させる項目です。
この分け方なら、構造が存在することと、読みやすく描画されたことを混同せず、自分の原稿に採用するかを判断できます。現行Mac版の機能範囲は、Rune Studio公式サイトでも確認できます。