名前の字形と素材の連続性

元の表記を残してから表示方法を決める

人物名は、絵の中の印章、本文書体の台詞、検索するための制作台帳など、複数の場所に現れます。それぞれで使える表記や確認条件は異なります。一つの字幕で字が欠けたからといって、元の名前を全素材で置き換えてよいとは限りません。このツールは正確な元の文字列を記録し、人物を区別したまま、特定の素材と確認版に限って承認した代替を追跡します。

名前の読みの台帳は、表記に対応する読みと根拠を整理します。漫画のプルーフは横組みの配置を確認します。ここで解くのは「どの素材で、どの表記が承認され、制作条件を変えたとき何の確認が不足するか」という問題です。読みの生成、画像からの文字認識、端末に入っている書体の自動検査は行いません。

初期例の二つの表記を人物aへ結び付けたのは、架空の編集設定です。実在する名前でその文字を交換してよいという文化上の主張ではありません。同じように見える表記を持つ別人bも登場します。実在の人物が望む表記は適切に確認する必要があり、視覚的な近さや符号上の関係から許可を推定することはできません。

表記IDと人物IDを混ぜない

表記の行は、表記ID、人物ID、正確な文字列です。一人の架空人物に複数の表記を結び付けられます。別の人物が同じ文字列を使うこともあります。人物IDは物語上の対応を、表記IDは文字で示す形を識別します。どちらも正規化した表示名そのものを識別子にして置き換えないでください。

元の文字列はそのまま保持し、Unicodeのコードポイントを併記します。コピーの途中で文字列が変わっていないかを見る材料になります。ただしコードポイントの列は、描画した字の画像でも、文化上の説明でも、書体に必要な字がある証明でもありません。制作が特定の並びに依存するなら、その並びを残して実際の出力を別に確認します。

Unicodeの正規化は、符号化したテキストに対する一定の変換を定めるものです。二つの物語内の表記が同じ人物を指すという作者の判断は、それだけでは得られません。そのため、このツールは表示文字列を正規化して表記を選んだり人物を統合したりしません。正規化の技術的な範囲は参考資料で確認でき、素材ごとの承認モデルは本プロジェクトの編集方法です。

確認記録には制作条件を付ける

素材の行には、固定の素材ID、現在の書体または絵の確認版、任意の比較版を入れます。caption-font-v1、ink-art-v2など、後でその制作条件を取り出せるラベルを使います。ラベルは自動検出した書体の指紋ではありません。ファイル、書体、出力条件、関係する絵が変わったなら、古い確認を新しい根拠として流用せず、新しい版を設けてください。

使用箇所は、そのIDを素材と元の表記に結びます。前の版で代替を使っていた場合でも、解決の起点は元の表記です。代替を重ねるうちに、最初に何を選んだのかが失われるのを防ぐためです。現在の表示が変わっても、人物と元の表記は結果と書き出しに残ります。

確認の行には、素材、版、表記ID、supported・missing・unknownのいずれか、根拠メモを記します。supportedは、その条件で表示を確認したという利用者の記録です。missingは問題を確認したという記録、unknownはどちらとも確認していない状態です。観察した状態にはメモが必要です。同じキーの重複は、矛盾する記録から勝手に一つを選ばないようエラーにします。

表示できることと代替の承認は別

代替の承認には、素材、版、元の表記ID、代替の表記ID、編集上の理由を入力します。両方の表記が同じ人物に属していなければなりません。文字列が似ているからといって、別人の台詞へ割り当て直す許可にはなりません。また、一つの承認を全素材、全書体版へ広げません。制作上の妥協なのか、物語内の別表記なのかが後で分かる理由を残します。

処理は元の表記から始めます。supportedなら、その表記を維持します。unknownなら確認が必要とし、欠落したとは仮定しません。missingなら、その素材と版で承認された経路をたどれます。その先の表記にも確認記録が必要です。代替として承認しただけで、実際に表示できることまで確認した扱いにはなりません。

複数の代替をたどる場合も、missingの観察と限定した承認を一段ずつ確認し、supportedへ到達して初めて解決します。一つの元表記から二つの承認が出るなら競合です。循環は経路付きで拒否します。現在の観察では途中で止まるとしても、矛盾した承認関係を将来の書体変更まで隠しておかないためです。

印章と字幕の初期例を追う

初期例の印章はv1を起点にします。現在の絵の確認がsupportedなので元の表記が残ります。比較する絵にもsupportedの記録があります。同じ元表記を持つ字幕では、現在の書体でmissingと入力しています。字幕だけに限定した承認からv2へ進み、v2にはsupportedがあります。印章を変えずに、字幕の表示を解決できる構造です。

三つ目の使用箇所はv3を通じて人物bに属します。表示する文字列は字幕の代替と同じですが、人物は別です。v1の承認はこの人物には適用しません。現在の字幕が解決する根拠は、v3自身の確認記録です。同姓の無関係な人物がいる作品や、同じ表示を持つ制作上の別レコードを管理するときに必要な区別です。

比較する字幕の版にはunknownがあります。現在は解決していても、比較版では確認が不足すると表示します。以前の書体の観察や承認は借りません。新しい書体を採用するには、実際のプルーフを見て記録を更新し、本当に代替が必要な場合だけ、その版へ限定した承認を設けます。

創作例：変えてはいけない印章

文庫版のデザイナーから届いたプルーフには、家名の一字が欠けた四角で表示されていた。漫画の元の絵では、同じ名前が通行許可証の赤い印章に入っている。そちらの字ははっきり見えていた。

「字幕の表記に全部そろえませんか。ファイルの中も一致します」とデザイナーは提案した。

作者は許可証を見た。三章後、登場人物が印章の下の線を横切る傷に気付く。その傷が、鍵のかかった事務室にある印と許可証を結び付ける予定だった。字幕へ合わせて名前を描き直せば、読者に先に見せた小道具まで変わる。

レタリング担当は問いを分けた。「字幕のプルーフに字がないのでしょうか。それとも、印章の絵まで使えなくなったのでしょうか」

それまでの一覧には、名前と書体の欄しかなかったため、二つが一つの問題に見えていた。

チームは作者が選んだ字幕用の別表記を登録し、同じ架空人物のIDへ結び付けた。印章の使用箇所には元の表記を残した。字幕には現在の確認版だけに限定した代替の承認を付けた。理由は制作上の判断であり、同じ字を使う現実のすべての人の名前について述べたものではなかった。

次のプルーフでは、字幕の書体が変わった。前の代替は表示されていたが、新しい書体で元の表記を試した人はいなかった。台帳は成功とせず、確認が不明だと表示した。デザイナーが元の表記を確認すると、新しい出力では正しく見えた。

その条件で元の表記をsupportedと記録し、代替を必要としなくなった。古い承認は最初の文庫版の判断を説明するために残した。漫画の絵では、傷は読者が見つけるべき場所に維持された。印を見分ける人物も、予定した推論を行うことができた。

これはオリジナルの架空の制作場面です。特定の字形が文化的に同じ、法的に交換可能、ある出版ソフトで互換性がある、と証明する例ではありません。一か所の表示問題と、すべての表記を書き換える許可を混同したときの代償を示しています。

違う選択なら手掛かりはどう変わるか

印章まで一括置換すれば、視覚的な証拠も変わるかもしれません。線を横切る傷が消える、位置が動く、目立たなくなる、といった変化です。最後の開示が、読者に実際には見せていない印を前提にしてしまう可能性があります。表計算の一致を取り戻すために、物語の一貫性を弱めることになるのです。

反対に、字幕を確認せず元の表記を全箇所で維持するだけでも十分ではありません。読者は普通の会話で欠けた字を見ることになります。必要な判断は範囲を限定することです。手掛かりを担う絵は残し、制作条件が求める場所でだけ読める字幕の別表記を承認する。同じ人物IDが各レコードをつなぎ、すべての面を同じにする必要をなくします。

自分の作品では、名前の現れ方が何をするかを考えてください。通常の台詞、公的な碑文、偽名、偽造文書の誤記、絵の手掛かり。同じ代替でも、ある用途では成立し、別の用途では機能を壊します。処理は承認した経路を示しますが、理由の欄にはその使用箇所の働きをどう維持するかを書く必要があります。

不明な確認を表示可能と扱わない

needs-proofは元の表記または到達した代替に、表示できる・欠落したという観察がない状態です。missing-unapprovedは欠落の記録はあるが、次に使える承認がない状態です。前者ではプルーフを確認し、後者では代替の判断を検討します。承認を一つ追加しただけで、不明な表示が確認済みになることはありません。

未解決のカードは元の表記を参照として残し、使用可能な代替ではないと明示します。人物の欄を空にしてしまわず、承認済みの表示を作れなかった理由も維持するためです。書き出すchosenVariantIdには、規則に沿ってsupportedへ到達した場合だけ値が入ります。

比較版は任意です。設定しなければ未設定と表示し、悪化したと推定しません。設定した場合は素材ごとに現在と比較版を評価します。印章の確認は字幕の書体の証拠にはならず、一つの表記を確認したことは、画面で似て見える別の表記の確認にもなりません。

確認できる大きさで制作へ渡す

各表は200行までで、入力全体にも上限があります。大きな制作は名前を付けた素材群へ分けます。群をまたいで同じ版ラベルを一貫して使い、未確認のファイルも別に一覧化してください。解決した行数は入力したマニフェストの範囲を示し、出版物全体の完了数ではありません。

書き出すマニフェストには表記、コードポイント、使用箇所、経路、利用者の観察、承認、比較結果が含まれます。元の画像と書体プルーフは自分のプロジェクトで保管します。根拠メモの内容をサイトが読み取ったり、承認者を認証したりすることはありません。書体の利用許諾や原稿の再配布権も確認しません。

公開前には実際のページを見て、選んだ表記が本当に採用されたか確認します。技術上解決した経路も、納品する素材と対応して初めて役立ちます。読みが問題なら読みの台帳、配置が変わるなら漫画のプルーフ、人物の設定そのものを改めるなら改名の依存関係へ進んでください。異なる判断を一つの名前欄へ押し込まず、それぞれの記録を残します。

書体に含まれる字形を自動で調べますか

いいえ。supported、missing、unknownは素材と確認版を指定した利用者の観察です。実際の制作出力を確認して、取り出せる根拠をメモします。書体名を書くだけでは、プルーフを確認したことにはなりません。

代替を承認したのに未解決なのはなぜですか

承認は編集上の置換を許可し、確認記録はその条件で表示できるかを示します。missingやunknownの行は、承認が向いているだけではsupportedになりません。経路を見て不足する観察を確認してください。

文字列が同じなら同一人物ですか

いいえ。表示や正規化後の形が同じでも人物IDは別々に維持します。代替の経路は同じ人物内に限定します。IDの対応は作者が確認するもので、字形の見た目からソフトが推定するものではありません。

書体を変えたら前の承認を使えますか

新しい条件を確認して明示的に承認してください。以前の観察はその素材と版に付いたままです。比較結果は、変更後に不足した確認を示します。古いファイルとの関連だけで新しいファイルを確認済みにはしません。