名前のルビ対応と組版プルーフ

親文字とルビの対応から組版を始める

小さな注音でも、人物の紹介を変えることがあります。読者は名前の表記と、その近くに置かれた別の文字列を一緒に見ます。読みや意味の関係が組版の途中で移ると、同じ文字が残っていても、作者が決めていない対応をページが伝えてしまいます。この作業台では、何と何を結び付けるかを先に明示し、その後で指定した枠に収まるかを実測します。

使うのは、既に親文字と注音を持っている場合です。漫画のクレジット、人物紹介のカード、小説の見本、別の担当者に渡すHTMLなどを確認できます。漢字から読みを探すツールではありません。語源、命名の慣習、実在の日本語名としての自然さも認定しません。出典のある読みは資料台帳で根拠を管理し、本ページには対応を明示して渡してください。

初期例の芸名と読みは創作です。普通の名前の字幅が枠内でも、ルビの対応や注音のはみ出しが適切とは限りません。逆に、対応を保持するため枠を広げる必要もあります。配置の都合で注音を分けるのは、新しい創作上の判断です。余白の修正と同じ扱いで、黙って行わないためのプルーフです。

創作例：灯りの公演に載せる芸名

小さな灯りの公演では、衣装のスケッチの横に、出演者の縦長のクレジットを入れる予定だった。一人の出演者は「羽灯」と書き、全体に「ほの」という読みを選んでいた。この対応も公演も、本ガイドのための架空の設定である。辞書の読みや文字ごとの由来を説明するものではない。衣装箱には全体を一つの印として描き、初めて見る観客にも同じ名を紹介したかった。

プログラムの担当者は、羽に「ほ」、灯に「の」を付ける案を作った。短い二つの注音なら、狭い欄で扱いやすく見えた。衣装を仕上げていた人物が、その一字ずつの対応も出演者が選んだものかと尋ねた。担当者には、その判断の記録がなかった。文字を分けたのは読みの根拠を知っていたからでなく、配置を便利にするためだった。

出演者は、名前全体に一つの読みを結ぶ形を残したいと答えた。チームは元の記録を上書きせず、分割案を別のIDで比較した。そしてクレジット欄を少し広げ、衣装の絵を動かした。絵の面積は減ったが、本人が選んだ紹介は保てた。別のゲストの読みはまだ届いていなかったため、表記を残したまま未解決と示し、便利そうな読みで空欄を埋めなかった。

この場面で問題になるのは、自己紹介と共同制作での信頼です。一字ずつの対応を出演者が選ぶなら、分割案も成立します。ソフトはその意思を決めません。全体の読みを括弧で併記しても人物は紹介できますが、位置と見え方は変わります。もし全く別の表記へ改名したら、衣装箱の印と同じ人物であることを別に示す必要があります。自分の作品でも、まず場面で保ちたい関係を定め、枠の効率だけで名前の働きを決めないでください。

記録のIDと人物のIDを分ける

一つの記録にはid、person、base、順序付きのsegmentsを入れます。idはプルーフや制作上の使用箇所、personは名前の持ち主を識別します。一人に二つの案があっても、人物を二人にはしません。別人の表示が同じ場合も、それだけで記録を統合しません。programとsplit-proposalのようなIDで代案を区別すれば、まだ選んでいない案を採用済みと混同せずに渡せます。

全ての区分のbaseを順に結合すると、記録全体のbaseに正確に一致する必要があります。空白の不足、文字の省略、異なるUnicodeの列は矛盾になります。見た目が似ているからと正規化して通しません。制作ファイル間で表記を守るための条件であり、違いを気にせず扱ってよいという文化上の判断ではありません。

monoの親文字は一つの書記素です。組み合わせ文字や異体字セレクターを含む場合、コードポイント数と一つの書記素は一致しないことがあります。本ツールは環境のIntl.Segmenterで区切り、使えない場合に単純な文字数で代用しません。位置の表示に使うUTF-16の範囲も、字形や音の数とは別です。ファイル上の対応を追うための位置として読んでください。

三つの対応を使い分ける

plainは注音を付けない本文で、reading:nullを明示します。monoは一つの親書記素への注音、groupは作者が渡した区分全体への注音です。groupの読みを自動で一字ずつに配分しません。複数の対応が分かっている場合は、その根拠に沿って区分を入力します。グループのまま扱いたいなら、読みの長さを理由に分ける必要はありません。

W3Cの「Rules for Simple Placement of Japanese Ruby」は、モノルビ、グループルビ、熟語ルビなどの関係と配置上の検討を説明しています。本ページでは用語と対応を保つ考え方を参考にします。掲載されている2020年の文書はWorking Draftです。本ツールが配置の全方式を実装したことや、W3Cの承認を得たことは意味しません。出典と利用の範囲はガイドの末尾にも示します。

注音のある区分でreadingがnullなら、未入力のままです。plainのnullは注音不要の宣言なので、状態が違います。空文字や空白だけの注音を入れて、未解決を完成に見せることはできません。親文字を表示できても、その欄の完全なHTMLは保留します。読みの欠落を、収まりを良くする手段として扱わないでください。

初期例で変更の影響を追う

三つの例を残して実行します。programは羽灯全体にほのを結び、split-proposalは羽とほ、灯とのを明示して同じ人物を維持します。unresolved-creditは別人の星衣で、注音が未入力です。どの読みが正しいかを選ぶ結果ではなく、何を指定し何が不足しているかを比べる結果です。例の対応は全て創作の宣言として読んでください。

次に二番目の案だけを、全体に一つの注音を付けるgroupへ変えます。対応表とマークアップは変わり、親文字と人物IDは変わりません。区分の文字だけを短くして全体のbaseをそのままにすれば、正確な結合の条件で止まります。検証を通すために名前の文字を削る前に、どちらの表記を守りたかったのか確認してください。

plainと注音付きの区分を混在させ、意図した空白を一つのplainとして残すこともできます。括弧、間隔、別の注記がある制作物では、後から見た人が何に読みを付けたか分かる区切りが重要です。ソフトが受け入れることだけでなく、引き渡した担当者が同じ対応を再現できるかも考えます。元の記録を別の案に上書きせず比較すると、その違いを説明しやすくなります。

横組みと縦組みを実際の枠で試す

枠の幅と高さはCSS pxで40〜1000です。指定寸法には1pxの枠線と12pxの内余白を含みます。親文字は12〜80、ルビの比率は0.25〜1、行間の比率は1〜3で、小数も使えます。制作上の条件を限定して試す設定であり、読みやすさや美しさの普遍的な点数ではありません。出力の単位を、そのまま印刷の実寸と読み替えないでください。

横組みと縦組みでは、プルーフの実際のwriting-modeを変えます。縦組みの列は右から左へ進みます。どちらも物理的な幅と高さを確認するので、横に収まった名前が縦の進行方向では収まらない場合や、列が増える場合があります。結果を良く見せるため、注音や親文字を自動的に縮めません。変更は入力の条件として明示します。

枠がスマートフォンの画面より大きければ、プレビュー部分を局所的にスクロールできます。画面に合わせて制作寸法を縮めないためです。サイト上部のメニューに内部スクロールを設ける話とは別です。表示領域に収まることと、指定した制作枠に収まることを分け、枠と寸法の説明を一緒に確認してください。

このプルーフの方針では、注音付き区分を一つのinline-blockとして保持し、ルビを中央へ配置してover側に置きます。plainの空白も保持します。単純で明示したブラウザー上の方針であり、出版社ごとのはみ出し許容、熟語ルビの高度な処理、行の調整、絵に沿う禁則領域の全てを再現しません。矩形の枠を狭めるだけで、実際の絵との衝突を検査したことにはなりません。

実測の数値が示すこと

ブラウザーのフォント準備を待ってから、親文字、注音、plain本文の矩形を取得します。それらの全体の範囲を指定枠線の内側と比較し、幅、高さ、どの端からどれだけ超えるかを記録します。境界のごく小さな差には0.5 CSS pxの許容を使います。これは現在の描画の幾何的な確認で、読めた人数、発音の正しさ、作品の品質の測定ではありません。

JavaScriptが動く前のHTMLには、対応の静的な例と未測定の説明があります。規則だけでブラウザー上の収まりは確定しません。使える矩形を取得できなければ測定不可とし、幅ゼロで成功とは扱いません。未入力のルビがある場合には、見えている親文字を測れても、完全な注音が収まるとの証明にならないことを状態に残します。

明朝系、ゴシック系、等幅系の端末フォント候補を変えて比較できます。要求した書体がなければ代替書体が使われます。フォントの準備が終わり矩形が得られても、希望した書体で全ての字形が描かれたとは限りません。そのため収録の確認は不明と示します。実際に使うフォントファイル、組版アプリ、画像、印刷工程は、目的の制作環境で別に確認してください。

HTMLと寸法を引き渡す

完成した記録には、専用のHTMLコピーとHTML保存があります。親文字と注音はエスケープし、記号を実行可能な要素に変えません。ルビを扱わない環境向けに括弧のフォールバックも残し、指定した枠の設定を含めます。外部フォントの取得、スクリプト、原稿のアップロードを、そのファイルへ追加しません。ただし未公開の名前や読みを明かす創作資料にはなり得ます。

別のアプリがルビを使えなければ、対応表の括弧表現も参考になります。それは明示した代替表現で、同じ見え方の保証ではありません。複数の組、空白、括弧が移動先でどう扱われるかを確認します。未解決の記録では完全HTMLの操作を無効にし、読みがないまま完成した引き渡しに見せません。別の記録が完成していても、その状態を借りません。

寸法の保存は、記録ID、人物ID、対応、設定、実際の測定状態を保持します。一般の結果ファイルも私的な制作情報を含み得るので、共有相手と内容を確認してください。編集可能な条件を戻すならプロジェクトを保存します。スクリーンショットだけでは正確な対応を復元できません。プロジェクトの復元後も現在の環境で再描画し、以前の端末と同じ寸法になるとは約束しません。

失敗した理由を変えずに修正する

結合が合わないときは、全体のbaseと区分をつないだ列を照合します。まず空白やUnicodeの差を調べ、名前そのものの変更と区別してください。monoの矛盾なら、複数の書記素を単字対応として渡していないか確認します。全体の読みならgroupが意図に合う場合がありますが、ソフトの都合で読みを分配しません。対応を選ぶ根拠は作者の側で明示します。

はみ出しなら、超える端とその区分を見て、枠、組方向、書体、比率、行間を試します。元の対応を比較用に残せば、どの変更が原因か追いやすくなります。親文字が短く見えてもルビは枠を超え得ます。注音の未入力で表示が小さい案を、収まりの良い完成案として選ばないでください。必要なのは都合のよい表示ではなく、実際に使う資料です。

最終的には、どの対応を保ち、どの制作条件を変え、移動先で誰が確認するかを記録します。枠を広げる修正も、意図して芸名を変える選択もあり得ますが、後者は寸法以上のものを変えます。その違いを協力者が理解できるプルーフにしてください。新しい語源、別の人物、存在しない承認を作らず、作者が選んだ名の紹介を守ることが目的です。

確認された全体の読みを、漢字ごとに自動で分けられますか

分けません。根拠のある対応を明示するか、全体のgroupを保ちます。指定した分割を受け入れても、構造の検証であり読みの真実性は認定しません。

未解決の記録にも寸法があるのにHTML操作が無効なのはなぜですか

注音がなくても親文字は測れます。その寸法で完成したルビの収まりは証明できません。必要な注音が入力されるまで、その記録の完全HTMLは保留します。

フォント候補を選ぶと全字形の収録を確認できますか

できません。代替書体でも矩形は得られます。収録は不明のままとし、実際の制作環境で別に確認してください。

保存したプロジェクトを復元すると何が戻りますか

正確な対応と組版条件が戻り、現在のブラウザーで再描画します。以前の端末の寸法や承認を黙って復元するものではありません。