Fontmake is a command-line font compiler used to turn editable Glyphs, UFO and Designspace sources into OpenType or TrueType fonts. If you are preparing type for translation, multilingual publishing or a language with complex marks, the important question is not merely how to run fontmake. It is how to produce a reproducible font build that preserves the intended characters, family identity, shaping behavior and licensed source material.
A reliable fontmake workflow begins with a source inventory and an honest test sentence set, then compiles a development build, diagnoses errors in the source or intermediate processing, and checks actual layout in the software readers will use. Static and variable fonts need different checks. A successful command does not establish that every translated paragraph will display correctly, nor that a particular app understands every variable-font feature.
This practical guide explains fontmake for editors, translators, localization engineers, type designers and language-documentation teams working across scripts. It covers source selection, CLI commands, designspace axes, glyph compatibility, OpenType layout, regression testing, distribution, troubleshooting and handoff. No prior font-engineering experience is assumed; examples are illustrative and must be adapted to licensed font sources and the installed program version.
Quick answer: the safest route from source to readable text
Start by retaining the source files and documenting the font licence. Identify which writing systems must work, along with test words containing combining marks, punctuation, numerals and mixed-direction text. Verify the source has appropriate glyphs before compiling, and choose an output format that fits your target application. Run the compiler in a clean environment with a recorded version. Then inspect the resulting font, test it with real translated sentences and compare it against an approved visual baseline.
A useful success test is deliberately small: one word with a mark, one long proper name, one mixed-script paragraph and one line of numerals. Expand from those probes to a real article, mobile screen or print page. Any mismatch should be traced to source glyph data, shaping, application fallback or line layout before you declare the file ready. A font does not translate words; it makes the already translated words legible.
What fontmake does—and does not do
Fontmake orchestrates the conversion of editable font sources into binary font files. Common inputs include a Glyphs source, one or more UFO sources, and a Designspace file that defines masters and interpolation relationships. Outputs may include static OTF or TTF files and variable fonts, depending on source compatibility and options supported by the installed version. The exact argument set can change across releases, so ask the installed executable for its help and version rather than copying an old terminal transcript blindly.
Fontmake is not a language translation engine, spelling checker, font editor or display renderer. It does not decide whether a word was translated well. It also cannot repair absent glyph designs, a confused Unicode mapping or a badly specified diacritic anchor just by running successfully. Think of it as the assembly stage: the design source supplies the parts, compilation turns them into a usable file, and downstream readers reveal whether the assembly actually meets its purpose.
A translator encounters fontmake indirectly when a type foundry delivers a language expansion, an NGO maintains a custom writing system or a publisher needs consistent books in multiple languages. Understanding the build boundary lets the translation team ask a precise question instead of reporting that the translated PDF ‘looks strange’.
Choose the right source before issuing a command
An existing OTF is not the same thing as editable source. A project may contain a .glyphs file, several .ufo directories, a .designspace file, separate feature code, proof PDFs and exported binaries. Work with a controlled source snapshot, not a mix of files taken from different stages. Record who supplied it, which licence applies, which revision you were authorised to modify and which binary is currently approved.
A single-master font might need only one UFO source. A family with several weights or optical sizes may use a Designspace file describing masters, locations, axes and instances. When sources disagree about glyph names, metrics or contour structure, the mismatch is not a cosmetic problem; it may prevent interpolation or produce unexpected results. Confirm the editorial requirements before choosing the source. A reading app that uses only Regular text may not need a sophisticated variable family, while a responsive website might benefit from a continuous weight axis.
Avoid taking an unrelated font, adding a few letters and assuming distribution is permitted. Modification rights and embedding rights differ. The build log should therefore contain a source-and-licence note as well as technical details.
Set up a controlled environment
Use a Python environment appropriate for the current fontmake release. The project documentation describes installation through pip and gives current minimum Python requirements. A virtual environment prevents unrelated system packages from changing when dependencies are installed. For a team, capture the Python version, fontmake version, dependency lock or pinned versions, operating system and build commands. Reproducibility means another authorised person can rebuild and compare results; it does not mean binary hashes must remain identical across every tool version.
A practical starting sequence is: python3 -m venv .venv; activate the environment using your operating system’s instructions; python -m pip install fontmake; fontmake –version; fontmake –help. If installation fails, inspect the interpreter and package manager output before editing the font. A successful installation confirms only that the CLI is available, not that a font project is compilable.
Work in a writable development folder and keep the original sources untouched. Build outputs should go to a clearly labelled directory. Do not overwrite an approved release file during experimentation. This simple separation saves considerable confusion when several translators, designers and testers are exchanging screenshots.
First compilation: one static source
The basic examples in the official project use commands such as fontmake -u Source.ufo -o ttf or fontmake -g Source.glyphs -o otf, depending on source format and desired output. An output directory can be specified where the installed version supports the appropriate option. Always review fontmake –help, because a command copied from a different release may use flags whose behavior has changed.
Before compiling, inspect whether the source actually contains a named glyph for each required character. For a project with English, French and Vietnamese content, a phrase like ‘café, français, tiếng Việt’ is a useful opening probe but is not a complete coverage test. Vietnamese tones and combinations require more than a few precomposed letters in one example. Follow with language-specific editorial samples supplied by a knowledgeable reviewer.
After compilation, record the generated filename, date, compiler version and any warnings. Install or open the output only in a test environment. An especially dangerous habit is to compare a new font in one application with an older cached version in another and conclude that the compiler ignored a change.
Build formats: OTF and TTF are choices, not quality scores
An OTF and a TTF can both be legitimate outputs, but they may use different outline representations and toolchain paths. Pick the format based on your intended platforms, outlines, feature requirements and existing production pipeline. File extension alone does not establish multilingual capacity, accessibility, licensing or compatibility. For a publisher, the deciding evidence is whether the relevant rendering systems preserve the writing systems and layout features in real content.
Keep experimental OTF and TTF builds separate. If one displays differently, establish whether the difference concerns outlines, hinting, OpenType layout or application behavior. For print, compare at the intended point sizes and output device. For the web, compare ordinary body text, headings, weight changes and fallback behavior at several widths. For an app, include both operating-system families when they are supported.
Do not label one format ‘Unicode’ and the other ‘non-Unicode’. Unicode character mapping is a matter of the font’s mapping and supporting tables, not the extension on the file. Similarly, neither format guarantees that all ligatures, combining marks or cursive connections work correctly.
Understand what Designspace changes
Designspace provides a structured way to describe multiple design masters and the relationships between them. A weight axis can represent a progression from light to bold; a width axis might vary from condensed to expanded. Named instances are specific positions that a designer may want to export as conventional static members. This structure is valuable for multilingual families because independent master files need to agree on glyph identity and compatible geometry.
A Designspace file is not a script-language selector. It does not mean that moving a slider automatically changes translated text from one language to another. It describes design variation. A language-specific feature may still be needed to choose shapes appropriate to a language, and that feature must be authored and tested separately. Confusing design axes with linguistic substitution can lead to a user interface that appears to offer language support but merely changes letter width.
Read the source file with the design team: which masters exist, which axes are intended for users, which are internal, and which named instances should ship? For each answer, record a testing implication. The narrowest width often stresses long translations more than a regular proof page does.
A first variable-font build
The official fontmake documentation includes variable-font compilation from suitable sources, for example fontmake MyFont.glyphs -o variable. A Designspace project can be compiled through the corresponding Designspace input option, subject to the installed tool’s supported syntax. The command is only an entry point; a variable font requires masters that are structurally compatible where interpolation is expected.
Do not start by building an entire family and testing a single midpoint. Inspect extremes and meaningful named positions, especially around masters that have differing component structures or attachment data. A variable font may appear correct at its default coordinates but show a displaced accent at a heavy weight. Another may interpolate legibly in Latin while producing an awkward stacked-mark result in a lesser-tested script.
For each axis, prepare at least one paragraph and a few target strings at minimum, default and maximum positions. Include a translated button label that already presses its width budget. Document which axes and ranges the product will expose. Readers should not need to discover by accident that the smallest UI setting becomes unreadable in one language.
Contour compatibility is not optional
Interpolation depends on compatible descriptions of corresponding shapes. Consider two masters for an accented letter. If one master builds it from a reusable base plus a mark component while the other uses a different contour organization, the toolchain may need to decompose or normalize components. When it cannot resolve a mismatch, a build error can be the correct outcome: it prevents shipping a strange interpolation that would be harder to diagnose later.
The repair belongs in the editable source. Compare corresponding glyphs, contours, point order, component relationships and metrics. Do not hide an incompatibility by removing the character from a release merely to make the command return success. That is especially damaging when the removed glyph supports a language not used by the build engineer.
A useful failure report includes the glyph name, master pair, source revision and a screenshot or simple description of the deformation. Rebuild after one controlled source change, then inspect the whole interpolation range. The aim is not just to make one location look acceptable, but to preserve meaningful letterforms between all intended locations.
When source filters change the result
Fontmake coordinates libraries for tasks such as feature compilation, outline conversion and overlap handling. An error message may originate in a dependent library, not the front-end command. The project’s troubleshooting guide explicitly distinguishes issues in Glyphs conversion, pre-processing filters and variable-font compilation. Treat the stage named in the error as evidence about where to begin inspecting.
If a cubic-to-quadratic conversion produces a strange corner, compare the source outline and export. If components are decomposed unexpectedly, trace which construction method the source used. If a variable build fails after static members compile, examine compatibility and Designspace setup rather than blaming the translation text. Record the smallest source change that reproduces the problem.
Avoid switching numerous options at once. When a build fails, change one relevant variable, keep a copy of the original log, and verify the new output against the same test strings. In multilingual publishing, unexplained ‘fixes’ tend to return when the next language is added. A clear diagnosis is cheaper than a fragile one-off workaround.
Unicode mapping and missing glyphs
A font can compile even when the translated text contains characters for which it has no glyph. The reader may substitute another font, display an empty rectangle or omit a mark. Coverage review therefore begins with the actual source strings, not an assumed national alphabet. Combine letters, punctuation, digits, currency symbols, quotation styles and invisible controls that appear in the publication.
Construct a character inventory from representative approved translations. Record which code points are expected to be drawn by the project font and which are intentionally delegated to fallback. Then inspect the binary and rendered result. A string can appear correct while silently using another font for one character; a later layout system may choose a different fallback and change line breaks.
Do not equate the number of glyphs with the number of supported characters or languages. Some scripts need multiple contextual forms and marks; other glyphs serve ligatures or stylistic alternates without their own Unicode value. A coverage report and a shaping test answer different questions and both matter.
Combining marks, accents and stacked diacritics
For a language that uses stacked diacritics, adding the mark characters to a font is only the start. Their placement should be tested above and below relevant bases, with different consonants and vowels, and at multiple weights if the family varies. The same textual sequence may be encoded in precomposed or decomposed form. Both can matter in user-generated content and cross-platform copying.
Create a small corpus containing both representations where they are canonically equivalent, and compare appearance and text integrity. A design source may define anchors and mark features that place combining marks; an export that loses or misbuilds those features can leave marks floating. The compiler should not be blamed automatically until you inspect what was present in source and what reached the output.
A practical proof sheet includes tight line spacing, italic or bold use where applicable, and a narrow column. Marks can collide with neighboring lines even when an isolated glyph screenshot looks fine. Invite an expert reader of the language to review both legibility and conventional orthography.
Contextual shaping and script-specific forms
Arabic, Indic and several other writing systems use contextual shaping or ordered combinations that a simple one-character-one-glyph model cannot describe. A font output needs appropriate mapping and layout data, and a shaping engine in the consuming application. Fontmake can compile sources containing feature definitions, but it cannot guarantee that those definitions are semantically right.
Build a test suite around meaningful words, not arbitrary concatenations of characters alone. Include initial, medial and final forms where appropriate, vowel marks, repeated marks, numbers embedded in text and language-specific conventions. For the same source, compare output from an application with verified shaping support against the product under test. The difference may reveal an engine limitation or an incorrect font feature.
Be careful about declaring a test successful because a screenshot ‘looks Arabic’ or ‘looks Devanagari’. Skilled language readers notice distinctions that are invisible to a casual reviewer. Ask them to identify which word, character sequence or mark placement is wrong, and preserve that as a regression case.
OpenType features are data with consequences
Features such as kerning, ligatures, mark positioning and language-system substitutions can change rendered text without changing underlying characters. A font editor may show the intended source feature code while an exported binary omits a lookup or compiles a different order. Test the output, not only the source. Some features are optional stylistic choices; others are essential for normal script behavior.
For localization, document which feature behavior the product requires and which it merely permits. A book may prefer discretionary ligatures; a form field may need stable character selection; a specialist orthography may depend on a particular language-sensitive substitution. When a tester reports an incorrect appearance, capture the exact Unicode string, language tag, feature settings and rendering environment.
Keep the semantics separate. Font features are not a replacement for correct translation, normalised storage or appropriate language metadata. If a word requires a different spelling in another locale, the translator must supply that spelling. A font can choose different shapes but cannot responsibly infer a different lexical item.
Family names, style names and searchability
The font family name and style metadata influence how design software, operating systems and browsers find and group fonts. A compiled file with visually correct glyphs may still be unusable if Regular and Bold share confusing internal names, or if a variable face is presented as multiple conflicting families. Examine the generated output’s names in a font inspector and test the selection behavior in target apps.
Multilingual family names and naming records deserve deliberate planning. A localised family label is helpful only when its language tagging and identity remain coherent. Do not translate technical identifiers ad hoc in each app; a changed family name can disconnect existing documents from the expected font. Keep human-facing display names separate from stable machine-facing names where the format permits.
Test installation with a clean font cache and a fresh document. Open a saved publication containing the approved font and confirm it still selects the right face. Compare the dropdown identity with the metadata delivered to web CSS. A naming error often masquerades as a rendering bug because the wrong member was silently selected.
Test typography in the real destination
A font proof page is necessary, but it is not sufficient. A mobile interface may use shorter line-height, a game engine may implement fewer layout features, and a PDF pipeline may subset glyphs during embedding. The source font might look perfect in a desktop editor while causing missing marks in a downloaded document. Test the same strings across every supported destination class.
Design separate checks for a web article, a narrow button, an EPUB chapter, a slide title and a print proof if those destinations matter to the project. For each, record target size, weight, browser or reader, operating system and fallback chain. Compare not just letter shapes but also cursor selection, copy/paste, search and line wrapping. Text that looks correct but cannot be selected or found is not a fully usable publication.
Give reviewers a fixed set of instructions so their screenshots are comparable. They should avoid manually adjusting letter spacing or replacing words to ‘make the test pass’. The reported problem is the product’s behavior under a defined set of ordinary conditions.
Long translations and line-breaking pressure
Localization changes the length and rhythm of strings. One language may need more characters for a menu item, while another may use fewer words but taller marks or wider glyphs. A font release can make the problem better or worse through metrics and default spacing. Avoid claiming that a font can remove the need for responsive layout design.
Put the longest accepted translations into actual UI containers. Test at common viewport sizes, high text scaling, and a narrower weight or width setting if available. Observe whether clipping affects the last letter, whether an accent crosses a button boundary, and whether the language’s approved line-break rules are respected. A broken layout might require a product redesign rather than a new condensed font.
A useful report says, for example, ‘at 320 CSS pixels and 200% text zoom, the final two characters of this approved label are hidden’. That identifies an actionable constraint. ‘The German font is too long’ is neither fair to the language nor technically precise.
Variable axes and editorial consistency
Variable fonts give layout software additional choices, but those choices can introduce inconsistency if the design system does not control them. If the publisher uses weight 480 on one platform and 500 on another, readers may perceive the same translated article differently. Document axis defaults and permitted ranges, and require that design tokens map consistently to them.
Check whether the target application supports the axes it exposes. Some programs offer only conventional bold or regular selection even when an exported font supports continuous variation. Do not design a workflow that depends on an axis users cannot select. For print, specify actual proof settings; for the web, inspect computed styles and downloaded font files rather than relying on a design mockup alone.
A language reader should evaluate legibility at the extremes that the product genuinely ships. A stylised display face may look attractive in English but obscure dense diacritics in small text. If a font variation compromises an orthography, treat that as a product requirement to fix, not as a preference to be voted away.
Fallback fonts and mixed-script documents
A multilingual document frequently mixes scripts and symbols. It may contain a local-language paragraph followed by an English address, a URL, a currency symbol and a mathematical formula. When the primary family lacks part of the inventory, the rendering system selects fallback fonts according to its own rules. This can change baseline, stroke weight and line spacing even if every character appears.
Define a fallback policy in the application or publishing stylesheet. Test common cases such as quotation marks, en dashes, emoji, parentheses around right-to-left text and numerals. A fallback font that covers a character is not necessarily suitable for a particular orthographic convention. Where the publishing platform permits, explicit language tagging can help the renderer choose language-aware forms.
A successful fontmake build should be evaluated together with fallback behavior, not in isolation. If a headline changes height only when it contains a particular mark, investigate which font rendered the mark. Conversely, if the primary face deliberately excludes emoji, document that as a design decision rather than a compilation defect.
Measure regressions across releases
A language expansion can alter existing text unexpectedly. Adding mark anchors, correcting kerning pairs or changing glyph components may affect earlier layouts. Before release, compare the previous approved binary with the new candidate using identical content and rendering settings. Keep the old file, test strings, screenshots and a change log. A few representative articles reveal more than an aesthetic comparison of one alphabet chart.
Separate intended changes from unexpected regressions. A corrected accent collision may deliberately change pixels; that should be accepted after linguistic review. A new collision in a different word, however, needs investigation. For variable families, sample the axis range and key instances rather than inspecting only one default face. Automated screenshot comparisons can flag differences, but a human needs to decide whether they are improvements.
The goal is controlled change, not the absence of all visual differences. If a new version fixes a mark that was previously misplaced, a pixel-perfect test against the old output would be misleading. Pair automated evidence with documented editorial judgment.
Worked example: a book with five writing systems
Imagine a publisher preparing an educational reader that combines English, Vietnamese, Arabic, Hindi and a locally documented alphabet. The translator supplies approved text and a terminology list. The designer supplies a font source that was previously used only for English headings. A fontmake build completes successfully, and the publisher assumes the font is ready for all chapters. This would be a risky conclusion.
First inventory the actual characters from each approved chapter. Next compare them with the source’s mapping and shaping support. Build a candidate font, then produce proof pages using the same book styles. Invite knowledgeable readers to check real words. Record missing characters separately from misplaced marks and unexpectedly chosen fallback faces. Confirm that the book’s embedding method retains required font data.
The outcome may be that one font family covers the Latin chapters while another licensed family serves Arabic and Hindi. That is not a failure. It is an accurate production decision. A readable, searchable book matters more than forcing every language into a single binary that cannot meet the requirements.
Worked example: a variable font used in mobile navigation
A product team chooses a variable family for a multilingual navigation system. At the default width, most labels fit. The longest accepted translation overflows at the narrowest screen. A developer proposes lowering the width axis for that locale. Before accepting the change, the team should check the font’s intended width range, the appearance of diacritics and punctuation, and whether the smaller width remains readable.
The test matrix should include device width, text scaling, active font weight and axis values. The team may discover that the underlying layout has a fixed-height container and no sensible wrapping behavior. In that case changing the font does not address the root cause. Better options may include flexible layout, a second line or an accepted shorter translation that preserves meaning.
Document the decision with screenshots and approved strings. A future fontmake rebuild should re-run the same cases. Otherwise a harmless-looking tweak to another glyph can reintroduce the overflow in a later release.
Worked example: inconsistent accents after a source update
Suppose an accented character looks correct in a static Regular export but rises awkwardly in a variable Bold setting. The source file recently gained a new composite construction for that character. Do not begin by editing the translated word; the spelling is correct. Compare the glyph construction, anchors and interpolation across masters.
Ask whether the problem appears at every variable coordinate or only around a certain weight. Test other characters using the same mark anchor. If multiple letters fail together, a shared anchor or mark feature is a more plausible starting point than a text-entry mistake. If only one glyph fails, compare its source structure with related letters. Recompile after one narrow correction.
The final acceptance test should include both an isolated string and a paragraph using the font at normal line spacing. Readers rarely encounter a diacritic floating by itself on an empty page. They encounter lines of meaning, and the corrected mark must survive those conditions.
Worked example: the font works in a proof but fails in EPUB
An EPUB production team embeds a compiled typeface and sees correct pages in its desktop proofing tool. A reader on another device displays empty squares for a few characters. The first investigation should confirm which binary was embedded and whether the EPUB conversion or subsetting step changed it. Check whether the reader uses the declared embedded face or a system fallback.
Keep a minimal EPUB containing the failing words and compare it across readers. If the exact font binary works in one environment but not another, record the difference in renderer behavior and supported features. If both readers fail after packaging, examine the package’s font data and CSS references. Do not assume the compiler caused a corruption merely because it produced the original file.
The repair might be in EPUB packaging, file naming, licensing permissions or renderer compatibility. The lesson is to preserve a chain of evidence from editable source to build to packaged artifact. Translation QA that stops at the font export has not reached the end user.
Build logs, file identity and release notes
Every release should answer five questions without relying on one person’s memory: what sources were compiled, with which toolchain, into which output, for which languages and under whose approval? Store a build manifest with source revision, fontmake version, command, output checksum and test suite version. Keep names stable enough that a tester does not accidentally compare two similarly named files.
A reproducible run is valuable during a later complaint. If a customer shows a broken heading, the team can identify whether the binary in that build matches the approved one. Without a manifest, a support ticket often becomes a hunt through shared drives. Metadata also helps avoid accidental re-release of a font whose licence or attribution requires special handling.
The manifest is not a certificate of linguistic correctness. It is a map of what happened. Attach the signed-off language test report and known limitations alongside technical logs so future teams understand what the release was tested to do.
Troubleshooting: when the command exits with an error
Read the first meaningful error and the operation in which it occurred. A missing source path differs from an invalid glyph construction, and a Designspace mismatch differs from a failed package import. Confirm the invocation on the installed version, then reproduce with the smallest licensed sample that triggers the problem. Do not immediately upgrade every dependency on a production project without recording the old working environment.
If source validation identifies incompatible masters, repair the design source. If feature compilation fails, inspect the feature file, glyph names and referenced classes. If a Python dependency throws an exception, record the full stack trace and check the project’s documented compatibility requirements. When a build succeeds after an option change, review whether that option skipped a desired feature or changed the output requirements.
Keep the original error log intact. A useful bug report includes the OS, Python and fontmake versions, command, input types, simplified reproduction and observed versus expected behavior. Remove confidential or unlicensed materials before sharing. This helps maintainers diagnose the issue without making a language project public against its wishes.
Troubleshooting: when the command succeeds but text fails
A clean exit is not a quality pass. Start by categorising the visible problem. A missing character points toward coverage or subsetting; a floating accent suggests mark data or shaping; a wrong weight may be a naming or style-selection issue; a clipped line can arise from metrics or application layout. Do not treat all four as one generic ‘Unicode bug’.
Collect the exact string and its code points when appropriate. Note the language, direction, application, font file, font version, size and enabled features. Render a minimal comparison in a second known-capable engine. This isolates whether the output font itself is defective or whether the consuming application makes different choices. Keep a screenshot with context, not just a cropped single glyph that hides line spacing.
After a fix, rerun old regression examples as well as the new failing example. A narrowly correct visual repair can create another problem elsewhere, especially in connected scripts or variable outlines. The goal is a stable document, not one corrected screenshot.
Editorial quality gates for translation teams
A translation QA owner should not need to understand every detail of UFO source processing, but should own acceptance criteria. Require evidence that approved terms and characters are preserved, that content remains searchable and selectable, that right-to-left and mixed-script text displays correctly in supported destinations, and that there are no collisions at ordinary sizes. Include a meaningful way for a language reviewer to record a failed word and proposed correction.
Separate translation approval from font approval. A translator may certify the words, a linguist may review orthographic conventions, a designer may approve typography and an engineer may sign off on packaging. None of these roles substitutes entirely for the others. For a small team, one person may cover several responsibilities, but the checks should remain explicit.
Do not ask reviewers to invent test material on the spot. Supply an approved corpus with challenging cases and clear pass/fail questions. When a new language arrives, extend that corpus instead of replacing it. The result becomes an evolving record of the publication’s real linguistic obligations.
Accessibility and text integrity
The visible letterform is one part of accessible communication. Screen readers, search engines, copy/paste, keyboard navigation and text extraction depend on underlying text and document structure. The font must not hide an encoding error by drawing the right-looking glyph for the wrong character. If a text file contains an incorrect code point, fix the text upstream rather than using a special font mapping to disguise it.
Test copying an approved phrase from the final PDF or app into a plain-text editor. Compare the copied characters with the source, not merely the displayed appearance. Verify that headings and reading order remain meaningful after the production pipeline embeds or subsets fonts. In digital products, accessible scaling may reveal clipping that normal-sized proofs missed.
Readers using assistive technology deserve the same semantic text as everyone else. A beautiful font cannot compensate for a document whose language metadata, alt text or actual characters are wrong. Treat typography as a partner to accessible structure, not its replacement.
What to send when requesting help
When an external type designer or engineer is asked to fix a problem, send a minimal evidence pack: the affected word in native text, language and expected spelling, a screenshot with normal context, font binary name and checksum, source revision if sharing is permitted, render environment and exact reproduction steps. State whether the problem is new or existed in the previous release.
Avoid sending only the screenshot. A visually similar glyph may correspond to a different character sequence, and the engineer cannot infer code points reliably from pixels. Likewise, avoid sending an entire confidential manuscript when one paragraph would reproduce the issue. Preserve community consent and rights when working with recorded or unpublished languages.
Describe the desired result in terms the language reviewer can verify: ‘the second tone mark must sit above the first without collision’ or ‘the label must wrap without hiding the final word’. That is more helpful than asking someone to ‘make the font more international’.
A release checklist that can be audited
Before release, confirm the sources and licence, target languages, Unicode inventory, build environment, output format, family naming, intended axes and feature settings. Check compilation warnings; inspect binary properties; run text and visual regression examples; confirm fallback behavior in representative applications; and review the actual package rather than a loose development font. Sign off known limitations explicitly.
When a check fails, decide whether to block release, fix upstream or document a supported workaround. A serious failure in an affected language should not be excused because English samples pass. Neither should every harmless visual difference trigger a release freeze. Decisions should be proportionate to meaning, legibility and the actual use case.
Finally archive the approved source snapshot, binary, manifest and tests. A successor team should be able to explain why this version shipped and how to reproduce the result. That is the difference between a font file that happens to work and a maintainable multilingual publishing system.
FAQ: does fontmake translate or transliterate text?
No. Fontmake compiles font design sources into output font files. The translator chooses words and spelling; a transliteration system may transform written forms; a font is responsible for drawing text according to its mappings and shaping rules. If a sentence is mistranslated, recompiling the font will not correct its meaning. If a correct translation contains missing squares, the team should investigate glyph coverage, font fallback, shaping and packaging.
FAQ: do all languages need one universal font?
No. A good multilingual product may use a carefully chosen family for some scripts and a separate licensed face for others. What matters is consistent legibility, proper rendering and transparent fallback. A single file can be convenient, but an enormous font without careful script-specific design can be less effective than several well-tested fonts. Choose based on actual content, target software and readers’ needs.
FAQ: are variable fonts always better for localization?
Not automatically. They offer design flexibility and can reduce some packaging complexity, but they also require compatible masters, proper application support and tests across the relevant axis range. A static Regular face with excellent mark placement may be preferable to a variable family whose extreme locations fail. The right choice follows the publishing requirements and the available maintenance resources.
FAQ: can a successful build certify language support?
No. Compilation verifies that the build pipeline completed according to its technical rules. Language support requires evidence from approved content, shaping and rendering tests, plus review by someone competent in the orthography. Treat a successful build as a necessary checkpoint, not the final certificate. A few representative test words are useful; a genuine release requires broader coverage and an application-level pass.
FAQ: should I overwrite the old font after testing?
Keep the last approved release available and identify each new candidate unambiguously. Test with an explicit version and compare behavior before replacing a production file. Font caches and application caches can make an update appear inconsistent, so your rollout plan should include clear file identity and a way to revert. Save the original licensed source separately from generated binaries.
Official documentation and next reading
For current syntax, installation and troubleshooting, use the official fontmake repository at https://github.com/googlefonts/fontmake and the associated troubleshooting guide. These are more reliable than a frozen command copied into a production checklist. For adjacent tasks, the eduKateSG guide to fontTools pyftsubset covers removing unneeded glyphs and building webfont subsets, while the HarfBuzz guide addresses the actual shaping of connected scripts. The FontBakery guide addresses profile-driven release checks. They answer different questions; this article is specifically about compiling editable source files into release candidates.
Related eduKateSG reading: https://edukatesg.com/2026/11/13/translate-like-a-pro-12410-fontbakery-cli-opentype-universal-profiles-failures-reports-multilingual-qa/ and https://edukatesg.com/2026/11/13/translate-like-a-pro-12400-fontforge-unicode-glyph-design-metrics-opentype-export-multilingual-font-qa/ . Keep those pages as existing references; this new guide does not change their scope. The practical endpoint is a font build that the translator, designer and publishing engineer can all identify and test.