Name glyph & asset continuity

Preserve the form before deciding how to display it

A character's name may exist as a stamp in artwork, a caption in a text font and a searchable production record. Those surfaces can have different constraints. A missing glyph in one caption is not permission to replace every occurrence of the original name. This workbench records exact authored forms, identifies the person behind them and follows approved fallbacks within a particular asset and proof version.

Use this task when the problem is continuity across written representations. The Japanese reading ledger answers which reading and evidence belong to a form; the comic proof tool examines horizontal text layout. This page answers which exact written form has been approved on which asset, and what becomes unresolved when its production context changes. It does not generate readings, recognize text in images or inspect fonts installed on your computer.

The default forms are a fictional editorial fixture. Two variants belong to person a and an identical-looking display string belongs to person b. That assignment demonstrates a workflow, not a cultural claim that particular characters are interchangeable in actual family names. A real person's preferred form requires appropriate confirmation; this software does not derive permission from visual resemblance or an encoded relationship.

Keep variant IDs separate from person IDs

Each form row has a variant ID, person ID and exact written string. Different variants may belong to the same authored person. Two people may also share a string. The person ID expresses the story decision; the variant ID identifies the written representation. Neither should be replaced by a normalized display name used as a database key.

The tool preserves the original input string and lists its Unicode code points. That record helps you notice when a copied form has changed. It is not a photograph of a rendered glyph, a cultural explanation or proof that a font supports every character. If a source includes a sequence your workflow depends on, preserve that sequence and test the actual production output separately.

Unicode normalization defines particular transformations for encoded text. It does not supply the author's decision that two fictional references name one person. This tool therefore does not normalize its display strings to choose a variant or merge identity records. The linked Unicode normalization annex supports the technical distinction; the asset approval model is our own editorial method. The page is not a general-purpose Unicode conformance checker.

Give each proof a production context

An asset row contains a stable asset ID, a current font or artwork proof version, and an optional comparison version. The label should identify a context you can retrieve, such as caption-font-v1 or ink-art-v2. It is not an automatically detected font fingerprint. If the file, font, export settings or relevant artwork changes, use a new proof version rather than relabeling old observations as new evidence.

An occurrence connects its ID to one asset and its original variant. The original is the starting point of resolution even when another version was used in a previous edition. This prevents a chain of successive fallbacks from gradually erasing the source decision. The current display can change while the person and original variant remain available for inspection and export.

Proof rows record asset, version, variant, supported/missing/unknown and an evidence note. Supported means you report having reviewed that form in that context. Missing means you report a problem. Unknown means the check has not established either state. Observed states need a note. A repeated key is rejected because two conflicting observations cannot silently compete for the same proof slot.

Approval and support are different requirements

A fallback approval gives an asset, version, source variant, replacement variant and editorial reason. Both variants must belong to the same person. Approval cannot reassign a caption to another person who happens to share the preferred string. It also cannot license a replacement across every asset or font version. The reason belongs in the record so the next editor can distinguish a production compromise from a story-driven alternate form.

The resolver starts at the original variant. If its proof is supported, it keeps that form. If its proof is unknown, it reports that proof is needed and does not assume a missing glyph. If it is missing, the resolver can follow an approved edge for that exact asset and version. It then checks the target's proof. An approved target that is itself missing or unknown is not automatically usable.

A sequence of approved fallbacks can continue only through explicit missing observations and scoped edges until it reaches a supported form. Duplicate outgoing approvals conflict. Cycles are rejected with their path even if a particular current proof would stop before traversing the cycle. An incoherent approval graph should not wait for a future font change to become visible.

Work through the stamp and caption example

The default stamp occurrence starts from v1. Its current artwork proof reports supported, so the original display remains. Its comparison artwork also has a supplied supported observation. The caption starts from that same original variant, but its current proof reports missing. A caption-only approval points to v2, whose current proof reports supported. That produces an approved caption display without changing the stamp.

A third occurrence belongs to person b through v3. Its display matches the caption fallback text, but its identity is separate. The approval for v1 does not apply to it. Its own supplied proof is the reason its current caption resolves. This distinction is useful when a cast contains unrelated people with the same surname or when two production records happen to render alike.

The comparison caption version has unknown observations. The tool reports a regression from a resolved current occurrence to a comparison context requiring proof. It does not borrow the earlier font's support or earlier approval. To adopt the new font, review the actual proof, record its observations and add a new scoped approval only if that context genuinely needs one.

Original fictional scene: the seal that should not change

The paperback designer sent a proof with a square where one character of the family name should have been. In the comic's original artwork, the same name appeared inside a red seal on a shipping permit. The seal was perfectly visible.

“Use the caption form everywhere,” the designer suggested. “Then the files agree.”

The writer looked at the permit. Three chapters later, a character would notice a scratch crossing the seal's lower stroke. That damage connected the permit to a stamp kept in a locked office. Redrawing the name to match the caption would also change the prop the reader had already seen.

The lettering editor asked a narrower question. Was the original form missing from the caption proof, or had the stamp artwork itself become unusable? The two questions had been treated as one because the production checklist had only a name field and a font field.

They created a variant record for the authored caption alternate and kept both forms under the same fictional person's ID. The stamp occurrence retained its original variant. The caption received a fallback approval limited to its current font proof. The reason recorded a production decision, not a claim about every real person who might write either form.

On the next proof, the designer changed the caption font. The old substitute appeared, but nobody had reviewed the original in the new font. The ledger did not call that a success. It showed unknown proof and asked for a check. The designer tested the original and found it displayed correctly in the new output.

They removed the need for a fallback in that context by recording the original as supported. They did not delete the older approval, because it still explained the first paperback proof. In the comic artwork, the scratch remained exactly where the reader needed it. The character who recognized the stamp could still make the intended inference.

This is an original fictional production scene. The example does not establish a real glyph's cultural equivalence, a legal spelling rule or compatibility between this site and a publishing application. It demonstrates the cost of confusing a local rendering problem with permission to rewrite every representation of an identity.

If the family name on the seal were redrawn to match the caption instead, the reader's later comparison would refer to a changed prop. Giving the character an entirely different name would require a wider story and artwork revision, not just one font fallback. The narrower choice preserves the clue-bearing source while solving one surface's rendering problem.

A different choice would change the clue

If the team replaced the stamp globally, the visual evidence could change with it. The damage crossing a stroke might disappear, move or become less noticeable. The final reveal could then rely on a mark the reader had not actually been shown. Restoring consistency in a spreadsheet would have weakened consistency in the story.

Keeping the original everywhere without checking the caption would also be a poor solution. Readers would encounter a missing character in ordinary dialogue. The useful decision is scoped: retain the prop that carries the clue, and approve a readable caption alternate only where the production context requires it. The same person's identity links the records without forcing every surface to be identical.

Apply the method by asking what each written appearance does. Is it ordinary dialogue, an official inscription, a disguise, an error in a forged document or a clue in an illustration? A fallback can be acceptable for one function and destructive for another. The software traces approved paths, but the editorial reason should explain why that path preserves the function of the specific occurrence.

Read unresolved results without inventing support

Needs-proof means the starting form or a reached fallback has no supported or missing observation. Missing-unapproved means a supplied missing observation has no permitted next edge. Those states call for different work: obtain a proof in the first case, or consider an explicit alternative in the second. Adding an approval does not turn an unknown rendering into a tested observation.

When unresolved, the result card retains the original as a reference and labels it unresolved. It is not presented as a usable fallback. This avoids a misleading blank identity while preserving the reason the tool could not produce an approved display. The export includes chosenVariantId only when a supported form has actually been reached through the defined rules.

A comparison version is optional. Without one, the record says not configured rather than inventing a regression. If you do configure one, every asset is evaluated independently in both contexts. A supported stamp proof provides no evidence for a caption font, and a proof of one variant does not automatically support another variant merely because they look similar on screen.

Keep the handoff small enough to verify

Each table is limited to two hundred rows, and the shared input contract also has a size bound. Split a large production into named asset groups. Keep version labels stable across those groups and maintain a separate list of files not reviewed. The count of resolved rows describes the supplied manifest, not the entire publication.

Download the continuity manifest to retain forms, code points, occurrences, paths, supplied observations, approvals and the comparison result. Keep any underlying images and font proof files in your own project. Evidence notes are references you supply; the site does not inspect their contents or authenticate an approval. It also does not check font licensing or permission to redistribute a manuscript.

Before publication, inspect the actual page and confirm that the selected form is the form production used. A technically resolved path is useful only when it corresponds to the delivered asset. Return to the reading ledger if the written change raises a pronunciation question, to the comic proof tool if layout changes, and to rename migration if the story identity itself is being revised. Different decisions deserve different records.

Can the tool see which glyphs my font contains?

No. Supported, missing and unknown are your supplied observations for an exact asset and proof version. Inspect the actual production output and write a retrievable note. A font name alone does not constitute a reviewed proof.

Why is a fallback approved but still unresolved?

Approval permits an editorial substitution; proof establishes whether the proposed display works in that context. A missing or unknown target does not become supported because an approval points to it. Follow the path and obtain the missing observation.

Do identical strings mean the same person?

No. Person IDs remain separate, including when display strings or normalized forms match. Fallback edges must stay within one authored person. You must confirm that identity assignment; the tool cannot infer it from glyph resemblance.

Can I reuse a previous font approval after changing fonts?

Only by explicitly reviewing and approving the new context. Earlier observations stay attached to their asset and version. The comparison panel exposes unresolved states after a change so a new file is not declared checked by association.