Glyph Identity
A glyph has several identifiers in a working font. Its name lets you refer to it while designing and programming the font. Its index locates it in the font's current glyph order. Its Unicode assignments connect it to characters in text.
These properties can describe the same glyph without being interchangeable. Understanding their separate roles helps you recognize a naming problem without accidentally changing the characters the font supports.
Glyph Names
In FontLab, a glyph name is the principal human-readable identifier used during development. Names distinguish glyphs within a font and appear in expressions, construction recipes, classes, and feature code. The name a may identify the ordinary lowercase form, while a.ss01 identifies an alternative.

The Glyph panel keeps the glyph name and Unicode assignment in separate fields.
Each glyph needs its own name. Two glyphs intended to coexist cannot be distinguished by giving them the same name, even if their drawings differ. When a naming operation encounters a name already in use, the conflict needs an explicit resolution.
A name that tools can read
Development names use ASCII letters, digits, underscores, periods, and, where supported, hyphens. They are case-sensitive: A and a name different glyphs. Do not include spaces in a glyph name.
A period commonly separates a base name from a suffix. In a.smcp, the base connects the glyph to a, and the suffix suggests a small-capital form. In a.ss01, the suffix identifies an alternative associated with a stylistic set. The label makes the intended relationship recognizable; a suffix alone does not create the feature that selects the alternate.
An underscore commonly joins the parts of a ligature name. The name f_i indicates a form associated with the sequence f followed by i. The special name .notdef, used for a font's missing-glyph entry, is the familiar exception to the convention that a name does not begin with a period.
Hyphens require care in expressions because the same character can mean subtraction. A development name such as A-cy may need quotation marks when used as an expression operand. The name and the syntax surrounding it must remain distinguishable. On final-font export, production naming converts hyphenated names to standard forms; when current names are preserved and conversion is unavailable, camelCasing can turn Zhe-cy into ZheCy.
Production naming has additional restrictions. Where glyph names are retained in an OpenType font, their permitted form and length are constrained; a 63-character limit applies to the usual stored PostScript glyph names. Development names can exceed 63 characters, so a name useful in the source is not necessarily suitable unchanged in the output.
Renaming and references
Changing a name changes how other parts of the font refer to that glyph. It does not necessarily create a different glyph object or redraw its outlines. The practical question is whether references to the old name are updated along with the name itself.
For example, a class, a named group of glyphs, needs attention if it contains a.ss01 and that glyph is renamed. A rename operation can propagate the change to supported references according to its options, whereas an uncoordinated text change can leave a reference pointing to a name that no longer exists. Treat the name as part of the font's structure rather than as a caption with no consequences.
Glyph Indices
A glyph index is a glyph's position in the font's ordered collection, starting at zero. It is useful for identifying a position in a particular font file, but it is not a permanent name for a letterform.
Reordering glyphs changes the indices of the glyphs that move. Inserting or removing glyphs can change the positions of others. A glyph's index may therefore differ between two versions of the same font even when its name and intended character assignment remain unchanged.
The Font window's Index view presents the internal order. Drag-and-drop insertion and Font > Sort Glyphs are covered in Drag-and-Drop Operations. Other views can arrange cells by names, character assignments, or other criteria. A cell's position in such a display is not automatically its glyph index.
Use a glyph name when a readable development reference is needed. Use an index when the task specifically concerns the order or a particular compiled font. The same index in another font can identify a completely different glyph.
Unicode Codepoints
A Unicode assignment designates a glyph as an initial representation of a character. For example, U+0041 identifies the Latin capital letter A, regardless of the particular drawing the font supplies.
The assignment is optional. A font can contain useful glyphs that have no direct character mapping, and one glyph can have more than one mapping.
More than one assignment
A multi-encoded glyph has several Unicode codepoints assigned to it. Each codepoint remains a different character identifier, but their assignments map to the same initial glyph.
Sharing a glyph does not make the underlying characters interchangeable. A text engine can still apply different text-processing behavior to them. Decide whether the same glyph is appropriate for all the assigned characters, including their role in shaping and layout, rather than judging only whether they look alike in one sample.
A multi-encoded glyph can appear at several character positions in an encoding-based view while appearing only once in Index view. Those repeated positions do not necessarily represent separate glyph records. An edit to the shared drawing affects that one glyph wherever it is used.
No direct assignment
An unencoded glyph has no Unicode codepoint assigned. It can still be referenced by name during development or selected by the font's layout rules. Ligatures, stylistic alternatives, and construction helpers commonly work this way.
An unencoded alternate is not automatically a missing piece of the character repertoire. It may be deliberately reached from an encoded base glyph. Adding a character assignment merely to make every Unicode field nonempty can change how the font maps text and is not a general repair.
Private-use codepoints can make a form directly addressable within an agreed workflow, but they do not give that form a universal character meaning. Software and documents outside that agreement may interpret the text differently. A standard character assignment and a private convention serve different purposes.
FontLab's ordinary character assignments are Unicode-based. Legacy codepages can be displayed as coverage views, but choosing one does not replace the glyphs' Unicode assignments. For supported export formats requiring a legacy encoding, FontLab translates from Unicode assignments automatically; the coverage view is not a manual re-encoding step.
Name-Codepoint Coherence
Names and codepoints are independent, yet recognizable relationships between them help tools exchange data. A glyph named A would ordinarily map to U+0041. If it instead maps to a different letter, either the name or the assignment may need correction.
The Adobe Glyph List (AGL) provides mappings and rules for deriving character strings from glyph names. AGLFN, the Adobe Glyph List for New Fonts, supplies recommended names for a selected set of characters. These conventions can help software recover text when it has glyph names available. They do not guarantee correct extraction from every PDF or repair incorrect character data in a document.
FontLab checks coherence against its active naming table. A name-codepoint mismatch is a diagnostic result of that comparison, not a judgment made from the drawing's appearance.
| Indicator | Relationship to inspect |
|---|---|
| Red line at the cell caption | A recognized name implies a codepoint that the glyph does not carry, including a missing expected assignment |
| Red line at the cell caption | Recognized name and character information disagree about their association |
| Yellow line at the cell caption | The glyph has a Unicode assignment, but its name is not recognized by the mapping |
Custom names, suffixes, and private assignments need to be considered in context. Some control-character and private-use cases are treated specially; a single assignment in U+E000–U+F8FF, for example, is exempt from the unknown-name warning. A name absent from the table does not by itself prove that the glyph is invalid. Likewise, the absence of a line does not certify every aspect of the glyph's identity.
Before resolving a mismatch, decide which fact is correct: the intended character, the working name, or neither. Deriving a codepoint from a wrong name can make the fields agree while leaving the font wrong. For the tools that assign, generate, and rename these properties, see Managing Glyph Names and Codepoints.