Font Engineering: The Invisible Craft Behind Every Typeface
(opens in new window)The Hidden Discipline
When you think about how fonts are made, you probably imagine a designer carefully drawing letterforms adjusting curves, balancing stroke weights, refining shapes until they look just right. That picture is real, but it’s only half the story.
A finished typeface isn’t just a collection of pretty glyphs. It’s a piece of software. Every font file contains thousands of instructions that tell computers how to render characters, how to combine diacritical marks with base letters, how to swap between alternate forms depending on context, and how to behave consistently across macOS, Windows, iOS, Android, Adobe apps, web browsers, and office suites. Someone has to write those instructions. Someone has to build the pipeline that turns a designer’s work into a shippable product. Someone has to make sure the font doesn’t break when a user types Taiwanese Hokkien in Google Docs.
That someone is a font engineer.
Font engineering sits at the intersection of software development, linguistics, and typography. It’s a discipline that most people even most software engineers have never encountered. But for any typeface that goes beyond basic Latin letters, especially for Chinese, Japanese, and Korean fonts with tens of thousands of characters and complex writing system requirements, font engineering is what makes the difference between a design exercise and a working product.
Over the past few years at justfont, I’ve served as the font engineer on every typeface the studio has shipped. This article explains what that work actually involves, how I collaborate with type designers, and why font engineering matters far more than its invisibility suggests.
(opens in new window)Core Responsibilities
The simplest way to explain font engineering: a type designer decides what characters look like; a font engineer decides how they behave. In practice, the boundary is blurrier than that I design glyphs too, and designers understand technical constraints but the core distinction holds.
My work falls into several interconnected areas.
(opens in new window)OpenType Programming
OpenType is the technology standard that makes modern fonts intelligent. Instead of being static collections of shapes, OpenType fonts contain programmable rules that transform text in real time. When you type fi and it becomes a single connected ligature, that’s an OpenType feature.
When a calligraphic font varies the shape of repeated characters to mimic natural handwriting, that’s an OpenType feature. When a font automatically composes a base letter with diacritical marks into a single properly positioned glyph, that’s an OpenType feature.
I write these rules using AFDKO(opens in new window) (Adobe Font Development Kit for OpenType) and Glyphs(opens in new window) App’s built-in feature editor. The rules live inside the font’s GSUB (Glyph Substitution) table and define how character sequences should be transformed before rendering.
For Loksin (洛神行書), a calligraphy typeface created with Taiwanese calligraphy master Chen Yao-Cheng, I implemented the calt (Contextual Alternates) feature to solve a fundamental problem with digital calligraphy: repetition looks fake. In real handwriting, a calligrapher never writes the same character exactly the same way twice. But in a digital font, every instance of a character is identical which immediately makes the text look mechanical rather than handwritten.
I programmed substitution rules that detect when the same character appears twice in proximity either adjacent like 心心念念 or separated by another character like an ABA pattern and automatically swap the second occurrence with an alternate glyph. The effect is subtle but transformative: text set in Loksin reads like natural calligraphy rather than stamped-out shapes.
Building these rules required more than just writing code. I first had to identify which words in Mandarin Chinese, Taigi (Taiwanese Hokkien), Taiwanese Hakka, and Cantonese actually use reduplication patterns. I collected data from dictionaries, open source IME (Input Method Editor) libraries like Rime(opens in new window), and NLP (Natural Language Processing) text segmentation tools like jieba-Hakka.
The resulting reduplication dictionary covering AA, AAB, AABB, ABAB, ABAC, and other patterns across four languages became a dataset I released as open source(opens in new window) for other font engineers and linguists to use.
For The Write Right Font (就是不錯字), I pushed OpenType features into unexpected territory: automatic typo correction at the font level. Using the same contextual substitution mechanism, I programmed rules that detect common Chinese typos words where people select the wrong homophone from their input method and silently replace them with the correct characters. Typing 因該 displays as 應該. Typing 在次 displays as 再次. The correction happens inside the font itself, with no software or plugin required.
The interesting engineering challenge was preventing overcorrection. The character sequence 以經 is a typo when someone means 已經, but in the phrase 以經理的意見為主, the same two characters are perfectly correct 以 modifies 經理, not 經. I built context-aware exclusion rules that check surrounding characters before triggering substitutions, ensuring the font corrects genuine errors without mangling valid text.
(opens in new window)Unicode & Complex Text Layout
This is where font engineering intersects deeply with linguistics and standards. Unicode assigns code points to characters, but not every character combination has its own code point. For languages with diacritical marks and Taiwanese minority languages have many the font has to handle character composition at rendering time.
My most technically demanding work in this area was on Lanyang Ming (蘭陽明體), a Ming-style typeface designed to fully support Taiwanese Hokkien, Hakka, and indigenous language writing systems. These languages use Latin-based romanization with complex diacritical marks to represent tones. Taiwanese Hokkien’s Pe̍h-ōe-jī system alone has eight distinct tones, each represented by different combinations of diacritics on vowels.
The core problem: many of these diacritical combinations don’t have dedicated Unicode code points. An o with both an acute accent and a dot-above-right representing a specific tone on a specific vowel in Pe̍h-ōe-jī doesn’t exist as a single character in Unicode. It can only be represented as a sequence of separate code points: the base letter o, plus a combining acute accent, plus a combining dot-above-right.
Without engineering intervention, this sequence renders poorly. The diacritics stack incorrectly, overlap, or appear misaligned because the rendering engine doesn’t know how to position them. On proportional fonts (where i and M have different widths), a one-size-fits-all diacritical mark that looks fine over a narrow letter looks terrible over a wide one.
I implemented OpenType’s ccmp (Glyph Composition/Decomposition) feature to solve this. For every valid combination of base letter and diacritical marks used in Hokkien, Hakka, and indigenous romanization systems, I created dedicated composite glyphs precisely designed and positioned and wrote substitution rules that replace the multi-code-point sequences with these composites at render time. The rules also handle Unicode Canonical Equivalence: since o + acute + dot-above-right and o + dot-above-right + acute are canonically equivalent (the diacritics can arrive in either order), both sequences must resolve to the same glyph.
This work directly enabled Lanyang Ming to become one of the few typefaces in the world that fully supports the written forms of Taiwan’s minority languages languages that were previously impossible to typeset correctly because no fonts handled their diacritical requirements.
(opens in new window)Production Pipelines
A Chinese typeface contains at minimum 7,000 characters, and many contain over 15,000. Managing that volume of glyphs across multiple font weights, formats including TTF, OTF, WOFF, and WOFF2, and distribution channels requires automation. Manual export doesn’t scale.
For Open Huninn (open 粉圓), I built the entire production pipeline. Python scripts using FontTools(opens in new window) merge glyphs from multiple source fonts, validate character coverage against target character sets (jf7000 and Unihan standards), generate all required output formats, and run quality checks before each release. The pipeline also verifies metadata, naming tables, and rendering behavior all of which needed to meet Google Fonts’ strict quality standards when we submitted the font for inclusion in their library.
This pipeline reduced what would have been weeks of manual work per release cycle to a single automated run. More importantly, it made the project maintainable: when contributors submitted glyph improvements, the pipeline could validate and integrate them without risking regressions across the rest of the font.
For Wenwriting, justfont’s first collaboration with Adobe, the pipeline needed to meet Adobe Fonts’ specific technical requirements for distribution on their platform. Different platforms enforce different naming conventions, metadata structures, and format specifications. Engineering the font to ship correctly on Adobe Fonts while maintaining compatibility with justfont’s own distribution was a cross-platform engineering problem similar to what software developers face when deploying to multiple app stores.
(opens in new window)QA & Cross-Platform Testing
Font rendering varies significantly across platforms and applications. A glyph that looks correct in Adobe InDesign on macOS might render differently in Microsoft Word on Windows, or break entirely in a web browser on Android. OpenType features that work flawlessly in one text engine might be silently ignored by another.
I test every typeface across macOS, Windows, iOS, and Android, in applications ranging from professional design tools (Adobe Creative Suite, Glyphs) to office suites (Microsoft Office, Google Docs) to web browsers (Chrome, Safari, Firefox and Edge). For features like the contextual alternates in Loksin or the composition rules in Lanyang Ming, I verify that the OpenType features trigger correctly in each environment and document workarounds for the ones that don’t fully support advanced features.
This testing process is especially critical for the minority language support in Lanyang Ming. Older operating systems and some text engines don’t properly implement Unicode normalization or OpenType composition, which means the carefully engineered diacritical combinations might not render correctly everywhere. I implement progressive enhancement strategies: the font works best in modern environments with full OpenType support, degrades gracefully in older environments, and never produces broken or unreadable output.
(opens in new window)Designer Collaboration
The relationship between a font engineer and a type designer is like the relationship between a frontend engineer and a UI designer except the “product” is a file format that has to work everywhere, and the “users” are every application that renders text.
At justfont, the collaboration typically follows a pattern. The designer creates the visual identity: the stroke style, weight, proportions, and personality of the typeface. They design the core character set usually starting with the most common 500-1,000 characters that establish the font’s visual language. My job begins once the design direction is established.
First, I work with the designer to understand what the typeface needs to do beyond looking good. Does it need contextual alternates for natural-looking calligraphy? Does it need to support minority language romanization? What character sets does it need to cover? These conversations shape the engineering plan.
Then I build the technical infrastructure: setting up the OpenType features, defining character classes, writing substitution rules, configuring the font’s internal tables, and building the production pipeline. Throughout this process, I’m translating the designer’s creative intent into machine-executable instructions. When the Loksin designer wanted “handwriting that doesn’t look repetitive,” I had to figure out what that means in terms of calt rules, alternate glyph counts, and context window sizes. When the Lanyang Ming designer wanted “full support for Taiwanese languages,” I had to understand the linguistics deeply enough to implement it correctly.
The collaboration is iterative. I’ll implement a feature, the designer reviews how it affects the visual output, and we adjust. Sometimes the engineering reveals constraints the designer didn’t anticipate a substitution rule that works for Mandarin reduplication patterns might produce unexpected results in Hokkien. Sometimes the designer’s vision pushes me to find engineering solutions I hadn’t considered.
The most important skill in this collaboration isn’t technical it’s translation. Designers think in visual terms: rhythm, balance, texture, readability. Engineers think in logical terms: rules, conditions, edge cases, compatibility. My job is to bridge those two ways of thinking, ensuring that the designer’s creative vision is faithfully preserved in the final technical product.
(opens in new window)Why It Matters
Font engineering is invisible by design. When it’s done well, nobody notices text simply works. Characters compose correctly, alternates appear naturally, the font installs without issues on every platform. But when font engineering is missing or done poorly, the consequences are immediately visible: broken diacritics, mechanical-looking calligraphy, missing characters that render as blank squares, fonts that crash applications or display incorrectly across platforms.
The impact extends beyond aesthetics. My work on Lanyang Ming directly contributes to preserving Taiwan’s linguistic heritage. Taiwanese Hokkien, Hakka, and indigenous languages have been historically neglected in digital typesetting because the technical barriers were too high no fonts supported their writing systems correctly. By engineering proper diacritical composition and character coverage, I helped make it possible for speakers of these languages to write digitally in fonts that actually render their text correctly. That’s not a font feature it’s linguistic infrastructure.
The open source font work carries similar weight. Open Huninn, with its engineered production pipeline and Google Fonts distribution, made a complete Traditional Chinese rounded typeface freely available to anyone with a web browser. The automated pipeline I built means the community can continue improving it without font engineering expertise. The reduplication dictionary I compiled for Loksin is now available for other font engineers and NLP researchers working on Taiwanese languages.
At an industry level, font engineering is becoming more important, not less. Variable Fonts, color fonts, and increasingly complex OpenType features are expanding what fonts can do but each new capability requires engineering to implement correctly. The typeface industry’s shift toward subscription models and platform partnerships (like our Wenwriting collaboration with Adobe) adds distribution complexity that didn’t exist when fonts were simply files you installed on your computer.
For Chinese typography specifically, the scale of the engineering challenge is enormous. A Latin font engineer might deal with hundreds of glyphs; a Chinese font engineer deals with tens of thousands. Every OpenType rule, every character set analysis, every cross-platform test multiplies by orders of magnitude. The need for font engineers who understand both the technical systems and the linguistic context will only grow as more languages demand proper digital typesetting support.
(opens in new window)Key Learnings
Font engineering is the craft of making design work as software across every platform, every language, and every edge case that users will never think about but will immediately notice if it fails.
Three years of font engineering has taught me things that transfer far beyond typography.
Working with Unicode and complex text layout gave me a deep understanding of how text actually works in computers not the simplified version most developers encounter, but the full complexity of encoding, normalization, bidirectional text, and rendering pipelines. This knowledge has made me a better software engineer across every domain I work in.
Building OpenType features taught me that the best programming is invisible. The substitution rules I write are experienced by users as “the font looks natural” or “my language renders correctly.” Nobody sees the code; they only see the absence of problems. This philosophy engineering that disappears into the product shapes how I approach all software development.
Collaborating with type designers reinforced that the hardest engineering problems are often translation problems. The gap between creative intent and technical implementation is where the most valuable work happens. Learning to listen carefully, ask the right questions, and find solutions that preserve artistic vision within technical constraints is a skill that applies to any collaboration between engineers and non-engineers.
Most importantly, font engineering showed me that infrastructure work the kind of work nobody sees or celebrates can have outsized impact. Every time someone types Taiwanese Hokkien in Lanyang Ming and the diacritics render correctly, that’s my code running. Every time a calligrapher’s student sets text in Loksin and it looks like natural handwriting, that’s my code running. The work is invisible, and that’s exactly the point.