Pre-export font validation: a release gate that catches real failures

1. Separate readiness, validation, and visual approval

The Completion cockpit measures progress through Create, Complete, Refine, Test, and Ship for the selected release goal. Run validation performs worker checks against the current resolved project. These views overlap, but they answer different questions: readiness asks whether promised work is present, while validation reports structural errors and warnings.

Neither result certifies typographic quality. Typelure cannot infer whether a curve is elegant, spacing is balanced, contour winding is correct, overlaps should be removed, a path self-intersects, or a rasterizer will behave identically everywhere. Treat a clean result as permission to begin final proofing, not a substitute for it.

2. Lock naming and global metrics

Set Family, Style, Full Name, and Version before the last export. Typelure treats missing family or style as a validation error and tracks all four fields in ship readiness. Add Designer, Copyright, and License metadata before distribution so authorship and permitted use travel with the release.

Review Units per Em and the vertical system together. Typelure checks for finite values, a positive design area, a positive ascender, and a negative descender. For a conventional Latin design it also recommends the order ascender at or above cap height, cap height at or above x-height, x-height above the baseline, and descender below it.

• Family and Style identify the face users select.
• Full Name should agree with the intended family-and-style presentation.
• Version should change when a distributed build changes.
• Designer, copyright, and license fields should be explicit before sharing the file.
• Proof tall accents and deep descenders against the chosen vertical bounds; numeric order alone does not prevent clipping.

3. Audit mappings, fallback, spaces, and widths

Every encoded character should have one intended Unicode mapping. Typelure reports duplicates because two glyphs competing for the same code point make coverage ambiguous. It also expects a visible glyph named .notdef and a mapped U+0020 SPACE that is blank with a positive advance width. Confirm .notdef is the first glyph in the compiled font during external inspection because the current readiness check verifies the fallback by name, not final glyph order.

Ordinary spacing glyphs need finite, non-negative widths, and visible release-goal glyphs need positive widths for proof layout. Zero advance can be legitimate for recognized combining marks and nonspacing control glyphs; it is not a general way to hide an unfinished letter. Left side bearings must remain finite.

1. 1

   Confirm the selected goal

   Make sure the release promise—not the number of project glyphs—defines the required mappings.

2. 2

   Resolve duplicates

   Keep one intended encoded glyph for each repeated Unicode value.

3. 3

   Inspect blank characters

   SPACE must be blank and measurable; combining and control glyphs need widths appropriate to their Unicode role.

4. 4

   Check .notdef

   Keep a visible fallback outline with a usable width, then verify its final compiled glyph order externally.

4. Resolve components and inspect contour structure

Typelure resolves linked components before proofing, validation, and compilation. Broken references, duplicate component or instance identities, invalid transforms, or missing main placements prevent that resolution and should block export until the model is repaired.

For outlines created or modified in the project, validation checks finite coordinates, open contours, closed contours with too few points, and nearly overlapping consecutive points. Readiness also checks that required drawn contours are closed and contain at least three distinct endpoints.

These are structural tests, not a complete outline sanitizer. Inspect counters, winding, overlaps, self-intersections, extrema, handle continuity, and the filled result yourself. Simplify can remove redundant points, but use it as an editing operation whose visual result must be reviewed—not as an automatic repair button.

• Open every issue-linked glyph and identify the exact contour before editing.
• Close intended filled contours and delete accidental fragments.
• Remove duplicate points without flattening intentional corners.
• Edit a component at its main source when the correction belongs to every instance.
• Detach only when one instance genuinely needs independent geometry.

5. Proof the promise, then test the exported files

Use the goal proof strings first, then paste representative customer or product text into Outline proof. Check at small, normal, and large sizes with tracking at zero. Missing-character indicators help expose absent outlines, but only reading the text will expose uneven rhythm, collisions, weak punctuation, and awkward accents.

Export TTF for desktop testing and WOFF2 for a browser test. Reopen or install the TTF in applications outside Typelure. Load the WOFF2 through a real CSS font-face rule and verify the actual pages, fallback stack, line breaks, and missing-character behavior. Keep the editable project as the source of truth rather than editing an exported webfont.

• Spacing: HHOHOO AVATAR / nnonn Hamburgefontsiv
• Alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ / abcdefghijklmnopqrstuvwxyz
• Figures: 0123456789 00 11 88 / $€£¥ 12:34 99.9%
• Punctuation: “Quoted,” (grouped) — hyphenated… and apostrophe’s
• Everyday text: Sphinx of black quartz, judge my vow!
• Western European goal: Ça va? Élève, déjà vu. Straße. Pchnąć w tę łódź jeża.

6. Sign off with explicit evidence

Record the selected goal, project version, export version, validation result, reviewed warnings, proof strings, and applications or browsers tested. A repeatable checklist makes a later revision auditable and prevents a clean old build from being confused with an untested new one.

Use the OpenType specification to check the file model and naming records, and the WOFF2 Recommendation when validating a webfont deliverable. The final evidence remains the newly exported files running in their intended environments.

• Correct release goal selected and its coverage complete.
• Family, style, full name, version, attribution, and license reviewed.
• .notdef, SPACE, Unicode mappings, widths, and bearings reviewed.
• Every validation error fixed and every warning consciously accepted or fixed.
• Components resolve and edited contours pass structural checks.
• Proof strings read at multiple sizes with tracking at zero.
• Fresh TTF and WOFF2 exports tested outside Typelure.
• Source project and final artifacts stored with matching version notes.

Frequently asked questions

Primary references

These references support the standards and file-format details in this guide. Typelure-specific behavior is described from the current product implementation and is dated above.

• OpenType Font File — Microsoft Typography
• name — Naming Table — Microsoft Typography
• WOFF File Format 2.0 — World Wide Web Consortium