Proofing Environments

Proofing asks two questions: does the type work as a design, and does the delivered font behave correctly where it will be used? Keep both questions in the review plan.

Design and Interoperability

Design proofing examines the forms in use: text color, counter openness, spacing, kerning, marks, and the relationship between styles and sizes. Use running text and targeted strings. A beautiful enlarged glyph can still interrupt a line of text.

Interoperability concerns the font as usable software. Applications can differ in feature controls, font-menu grouping, shaping, line metrics, color support, and rasterization. A correct display in one application does not establish the same behavior everywhere.

Record the intended languages, applications, formats, and sizes before deciding which proofs are sufficient. Add a repeatable test whenever a problem is found so later revisions can be checked against it.

In-App Proofing Limitations

FontLab previews are useful because they show current source work immediately. They are not an exhaustive model of every operating system and application. Recall the rendering modes from The TrueType Hinting Model and Workspace: bilevel, grayscale, and subpixel behavior is chosen by the system, application, and display rather than by the font. TrueType rasterization and smoothing can therefore differ from the editor’s preview modes.

Source previews can also use relationships that are not yet present in an exported font: live anchors, visual kerning, editable recipes, or newly changed feature text that still needs compilation.

Technical proofing therefore requires exported font files and tests in the actual target environments; the production handoff is taught in The Export Process. First use the editor to resolve design problems, then confirm the compiled result rather than treating a native preview as a final delivery test.

Tools for In-App Proofing

Use the existing editing environments for their particular strengths:

  • Glyph-window text context shows forms with real neighbors.
  • Metrics mode helps judge default spacing without distracting contour detail.
  • Kerning mode exposes pair values, class coverage, and exceptions.
  • The TrueType waterfall shows Black-and-White/ClearType size-dependent behavior, a technical proof subject to the target-rendering caveat above.
  • FontAudit, taught in Font Audit, is the in-app first technical check on supported contour and interpolation faults.

Text mode and the Preview panel bring those decisions together in passages. Printed or exported proofs give reviewers a stable artifact, while Sketchboard text frames let you arrange several open fonts freely for comparison.

Keep the proof's settings with its result: source revision, master or instance, size, text, feature settings, and rendering mode. Without that context, a screenshot of a problem can be difficult to reproduce.