KDP向け横書き原稿は、本文が読めるだけで入稿準備完了にはなりません。段落、本文画像、表、極端に長い段落を別々に見て、ローカルプレビューで分かったことと、Kindle側でまだ分からないことを切り分けます。
今回の標本は3章、本文画像2枚、2列表1件、604字の長い段落1件です。開始値は章別文字数51字・69字・620字、見出しパターンh2、開いているタブ2枚。操作は標本作成と構造読取までで、横書きプレビューの肉眼確認は行っていません。statusは partial です。失敗時はこの未編集の3章標本へ戻します。
横書き確認を四つの観察点に分ける
製品に依存しない確認では、まず通常段落の改行と字下げ、次に画像の前後関係、表の2列が保たれるか、最後に604字段落の折り返しを見ます。四種類を一度に「見た目はよい」で閉じると、表だけ横にはみ出す、画像の直後だけ段落が詰まる、といった差を記録できません。
観察票には章名、対象要素、期待する並び、実際の表示、修正先を書きます。表示の問題があれば、プレビュー画面を直接直すのではなく、対応する原稿または画像・表の記述へ戻ります。修正後も同じ標本で再表示し、別の章へ不具合を移していないか確認します。
3章を同じ順で試す
第1章は短い本文と画像1枚、第2章は画像1枚と2列表、第3章は604字の長い段落を持つ構成にします。最初に3章の順、画像2枚、表1件、長段落1件を記録します。横書きへ切り替えたら、通常段落、画像、表、長段落の順に観察し、合否をまとめません。
表は「存在する」だけでなく、2列の対応が読めるかを見ます。画像は2枚の出現順と本文との位置関係を確認します。長段落は604字が欠けず、意図しない空白や重なりがないかを見ます。最後に表示を閉じて開き直し、3章と要素数が変わっていないことを確かめます。
Stage 4で読めたのは構造と開始値
記事固有の11操作では、3章、本文画像2枚、2列表1件、604字段落を準備しました。読み取り結果はpattern=h2、open_tabs=2、章別文字数51・69・620です。linked_scrollはnullでした。
この結果から、標本の要素と章別文字数は確認できます。一方、横書きプレビュー上で段落、画像、表、折り返しがどう見えたかは確認できません。画面取得が対象外だったため、構造の準備を表示成功へ読み替えず、partialを維持します。
Rune Studioの機能とKDPの結果は別
Rune Studioの公開資料では、プレビューを横書き・縦書きへ切り替え、編集に応じて更新できます。これはStage 3の製品機能です。今回のStage 4で肉眼表示を確認した証拠ではありません。
さらに、ローカルプレビューはKindle端末やKDPの受理結果を保証しません。入稿用ファイルを作った後はKindle PreviewerやKDPの現行資料で、端末別の見え方を別途確認する必要があります。この記事では外部確認を実施していないため、KDPで同じ表示になるとは書きません。
次の検証と停止条件
次は同じ3章標本をRune Studioの横書きプレビューで開き、四つの観察点を画面で記録します。その後、生成物をKindle Previewerへ渡し、少なくとも代表的な表示幅で同じ要素を再確認します。ローカルと外部の記録は別欄に残します。
記録票では、第1章の画像、第2章の画像と表、第3章の長段落に固有の番号を付けます。修正前後で同じ番号を追えば、「画像を直したら表の確認を忘れた」という抜けを防げます。画面幅や文字サイズを変えて試す場合も、一度に一条件だけ変え、最初の条件へ戻した結果を残します。KDP側で差が出たときはローカル表示を合格から取り消すのではなく、どの出力先で差が生じたかを別欄へ記録します。
長段落を短く直して合格させる前に、604字のままどこで崩れるかを記録します。表も画像化して逃げず、2列の読み順が保たれるかを先に見ます。標本を簡単にして問題を消すのではなく、原因を記録してから原稿上の修正を選ぶためです。
画像が2枚でない、表が2列として読めない、604字段落が欠ける、章順が違う場合は入稿を止め、未編集の3章標本と該当原稿へ戻ります。STUDIO-488の文字コード修正、494の画像パス、497の論理目次、551の編集フォントとは合格条件を混ぜません。本記事の結論は、標本準備は確認済み、横書きの肉眼表示とKDP側は未確認です。横書き・縦書きプレビューの公開範囲はRune Studioの商品ページで確認できます。
