横向きの数字で困らない！KDPのファイル形式、縦書き・横書きの形式選択

縦書き・横書きの形式選択の確認工程を、白い原稿用紙と紫色の半透明装置で抽象的に示したアイキャッチ

KDPへ出すファイル形式を選ぶとき、縦書きと横書きを同じ原稿で切り替えて比べるのは危険です。読む方向、数字・記号の扱い、ページ進行を先に分け、縦書き小説と横書き実用書を別のEPUBとして出力して判断します。

今回のStage 4では、二章の縦書き小説と二章の横書き実用書を別々に出力しました。両方ともローカル構造検査はvalid=trueで、縦書きだけが右開き、横書きは通常方向でした。ただし縦書き側の比較用記号は同一リテラル0件、横書き側は2件です。肉眼表示とKDP受理は未確認なので、結果はpartialです。

答えは原稿の読む方向から決める

一般的には、小説だから縦書き、実用書だから横書きと機械的に決めるのではなく、段落の流れ、数字、英字、表、URL、記号の比率で選びます。縦書き候補は右から左へ読むことを前提にし、2桁数字や!?の向きを確認します。横書き候補は左から右へ読み、数字やURLを通常方向で追えるかを見ます。

この記事の結論は「二つの候補を別成果物にし、読む方向と記号処理を比較してから採用する」です。固定レイアウトとリフローの選び方やKDPの審査結果は、ここでは選択根拠にしません。

二つの標本を混ぜずに用意する

縦書き標本は二章の小説、横書き標本は二章の実用書です。比較表には2桁数字と!?を入れます。本文を共通化して表示方式だけ変えるのではなく、実際に縦書きで読む文章と横書きで読む文章を別ファイルにします。

開始値として、章数2対2、候補形式2、記号位置を記録します。縦書き原稿を横書き成果物へ流用したり、同じ出力先へ上書きしたりしません。失敗時にどちらへ戻るか分からなくなるからです。

実際の操作では二冊を別々に出力する

Rune Studioの専用ワークスペースで、縦書き側は作品情報を日本語・縦書きにし、横書き側は日本語・横書きにします。それぞれ原稿を2章選び、別名のEPUBへ出力します。出力後は次を比較します。

構造値と肉眼表示は別判定です。右開きの指定があっても、数字や記号の向きが読みやすいとは限りません。

実測で確認できたのは方向の分離まで

タイトル固有の20操作では、縦書きEPUBと横書きEPUBを別々に生成し、両方valid=trueでした。縦書きはrtl=true、横書きはrtl=falseです。比較用マーカーは縦書き0件、横書き2件でした。縦書き0件は変換処理の可能性があるため、欠落とも成功とも断定しません。

共通Stage 4の別検証では、STUDIO-466検証本を4章、writingMode=vertical、版1.6で出力し、spine=8、画像1、欠落0、nav・NCXあり、valid=trueを確認しました。この値は縦書き生成の証拠であり、縦横比較の代わりにはしません。

したがって、今回確定できるのは「縦書きと横書きを別成果物にできた」「ページ進行方向を分離できた」の二点です。記号の見え方を含む最終選択は保留です。

限界と失敗時の戻し先

縦書きプレビューの肉眼表示、文字サイズ変更後の再配置、外部リーダー、KDP、iPadでの表示は未確認です。KDPはEPUBを受け付けますが、公式ヘルプでもKindle Previewerでの確認を勧めています。ローカルのvalid=trueをKDP受理へ読み替えません。

Rune Studioの製品範囲

現行Mac版Rune Studioは、6ページのEPUBウィザードで縦書き・横書き、原稿順、目次などを設定し、縦書きなら右から左、横書きなら通常方向のEPUB 3を出力します。縦書き時には2桁数字や感嘆符・疑問符の処理も公開資料に記載されています。これはStage 3の機能範囲です。

一般規格のEPUB 3.3仕様とRune Studioの操作、今回の実測、KDPの受理は別の段落で判断します。実装中のiPad機能は対象にしません。

結論：方向は選べたが表示は未確定

KDPのファイル形式で縦書き・横書きを選ぶなら、二冊を別々に出力し、右開きか通常方向かを先に比較します。今回、縦書きrtl=true、横書きrtl=false、両方valid=trueまでは確認できました。

一方、縦書き側の比較用マーカーは同一リテラル0件で、肉眼表示とKDP受理も未確認です。現時点では方向の選択だけを確認済みとし、最終形式は同じ二冊をKindle Previewerなどで見比べてから決めます。Rune Studioの商品ページでは現行Mac版の範囲を確認できます。

投稿日：