右開きを逆にしない！EPUBの縦書きCSS、2桁数字・感嘆符・顔文字の縦中横処理

EPUBの縦書きCSSで2桁数字・感嘆符・顔文字を扱うときは、機能説明だけで成功と判断せず、生成XHTMLで各文字列が実際にどう包まれたかを数えます。Rune Studioで二章の専用原稿を出力したところ、12、99、!?、!!は各4件が縦中横用の要素に入りましたが、(^_^)は4件とも入りませんでした。

さらに、非適用を期待したv12の中の12は縦中横用の要素に入りました。これは「期待どおりに自動処理できた」という成功例ではありません。顔文字の未適用と英字隣接数字の適用を見つけたからこそ、入稿前にXHTMLを確認する必要があります。

二章に5種類と4つの統制を置く

確認用原稿は二章に分け、12、99、!?、!!、(^_^)を各4件置きました。比較用として、長い数字2026、英字に続くv12、単独の!、通常の括弧文を各1件置きます。

ここで「適用候補」と「統制」を分けるのは、処理された件数だけでなく、処理してほしくない文字を巻き込んでいないかを見るためです。原文の場所を控えず合計数だけを見ると、別の12を数えて合格にする危険があります。

CSS、ページ進行、XHTMLを分けて開く

縦書きEPUBでは、少なくとも三つのファイル群を分けて確認します。

1. CSSでwriting-mode: vertical-rlと縦中横用のtext-combine-uprightが定義されているかを見る。
2. パッケージ文書でpage-progression-direction="rtl"になっているかを見る。
3. 各章のXHTMLで、対象文字がtext_combine_horiの要素に入った件数を数える。

vertical-rlは本文の書字方向、rtlはEPUBのページ進行、text-combine-uprightは対象文字を縦中横として扱うCSSです。役割が異なるため、どれか一つがあるだけで残りも正しいとは判断できません。

一般的なEPUBのパッケージ構造はEPUB 3.3で確認できます。Rune Studioの公開資料には縦書き、2桁数字、記号、顔文字の処理範囲が記載されていますが、個別の文字列がどう出力されたかは生成XHTMLの観察結果を優先します。

生成XHTMLで見つかった二つの不一致

専用原稿の出力結果は次のとおりでした。

CSSにはvertical-rlとtext-combine-uprightがあり、パッケージ文書にはrtlがありました。つまり縦書き用のCSSと右開き指定は存在します。それでも、顔文字(^_^)は結合されず、v12内の12は結合されました。

この結果を「16件成功、3統制成功」と丸めるのは危険です。タイトルの中心は、2桁数字、感嘆符、顔文字を種類別に扱うことです。顔文字と英字隣接数字で期待との差が出た以上、原稿の表記を見直すか、生成後のXHTMLを修正するか、別の出力方法を選ぶ判断が必要です。

文書化された機能と見た目の確認を混ぜない

今回、専用原稿から測れたのは、XHTMLの要素数、CSSの規則、パッケージ文書のrtlです。対応リーダーでの表示や、文字サイズを変えたときの顔文字・記号の見え方は確認していません。

入稿前は、次の順で自分の原稿を確かめてください。

1. 原文にある対象文字列と統制文字列へ番号を振る。
2. 生成XHTMLで一件ずつ対応させ、意図しない結合と未結合を記録する。
3. CSSのvertical-rlとtext-combine-upright、パッケージ文書のrtlを別々に確認する。
4. 使用するリーダーで文字サイズを変え、実際の見た目を確認する。

ローカル構造検査はvalid=true、欠落画像0件でしたが、これは販売先の受理や全リーダーの表示一致を示すものではありません。右から左へのページ送りも画面では未確認です。

自動処理の結果は適用と非適用の両側から見る

今回の二章では、12、99、!?、!!は各4件が結合されました。一方で、(^_^)は結合されず、v12内の12は結合されました。この不一致は失敗を隠す数字ではなく、生成XHTMLを点検して入稿可否を決めるための重要な判断材料です。

まず自分の原稿から、結合したい文字と結合したくない文字を一つずつ選んでください。Rune Studioの現行Mac版を候補にする場合は、詳しくはこちらで機能範囲を確認し、生成XHTMLと使用予定のリーダーで結果を確かめてから入稿します。