# Warcraft Font Merger merges two fonts and fills the missing CJK glyphs > Warcraft Font Merger is a small C toolchain that combines a Latin font with a CJK font and completes the result so that no character is missing, then packages the fonts for a World of Warcraft client. It is built on otfcc, ships as three executables of about 2 MB, and is single threaded by design. **nowar-fonts/Warcraft-Font-Merger** — Warcraft Font Merger，魔兽世界字体合并/补全工具。 - Repository: https://github.com/nowar-fonts/Warcraft-Font-Merger - Stars: 726 · Forks: 54 - Language: C - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/nowar-fonts-warcraft-font-merger ## The problem is two fonts that each cover half the script Warcraft Font Merger is a font merging and completion tool for World of Warcraft. The situation it addresses is specific to that game and to the way fonts get replaced in it. A player who installs a new Latin typeface for the interface usually also needs a CJK typeface, and the two come from different sources with different coverage. Merging them naively leaves characters that exist in only one of the two files missing from the result, which shows up in the game as blank glyphs in names, chat or quest text. The tool has three jobs, and the feature list in the documentation describes them as one package. It can merge two fonts, it can complete a font that has missing characters by pulling them from reference fonts, and it can generate a font package for the game. The completion step is the interesting one, because it is the step that the game actually needs: the output is a single TrueType file that covers both the Latin and the CJK range. The size story is part of the pitch. There are three executables totalling a little over 2 MB, and the archives that include the bundled fonts stay under 10 MB. Merging and completing a Chinese and English font pair takes about 20 seconds according to the documentation. The implementation is C, and it is not written from scratch. The programs that parse and generate OpenType font files come from otfcc by caryll, which is where most of the OpenType knowledge in this tool comes from. ## Four platform builds and three bundled font sets The release archives are split along two dimensions, the runtime platform and the bundled font set, and the file naming rule is WarFontMerger, then the bundled font set, then the version number, then the platform. Four 64-bit platforms are supported. The windows-x64 build has no runtime dependency and links against msvcrt.dll, and is listed for Intel, AMD and Zhaoxin processors. The windows-arm64 build has no runtime dependency and links against ucrtbase.dll, for Qualcomm, Microsoft SQx and other ARMv8 processors. The mac build requires macOS 10.15 or later and is a universal binary. The linux-amd64 build has no runtime dependency and is statically linked against musl, with other 64-bit architectures covered in the build and run section of the documentation. The bundled font sets are the other axis, and the choice matters because it decides which glyph shapes fill the missing characters. The XS set is a compressed font set covering GBK plus Korean Hangul, where the font file uses compression. The SC set covers GB18030 plus Korean Hangul and is the one the documentation recommends. The CL set also covers GB18030 plus Korean Hangul but uses glyph shapes closer to traditional printing. That recommendation is about visual consistency rather than coverage. The three sets differ in the shapes they draw for the same character, and SC is the one that matches what a Chinese player expects to see in the interface. ## One-step and two-step merging produce different glyph priorities The Windows workflow is drag and drop. Open the tool folder, select the two fonts you want to combine, and drag the Latin font onto the merge-and-complete batch script. After a short wait you get the merged font, named out.ttf. If you only want the two fonts merged with no completion step, the same drag is onto the separate merge script. Completion on its own works the same way, except you drag the single font you want completed onto the completion script and get out.ttf back. The subtlety, and the one to read twice, is that merging and completing in one pass is not the same as doing them in two passes. In a single pass the glyph priority runs in the order: first font, the Latin reference font, second font, the CJK reference font. In two passes it runs: first font, second font, the Latin reference font, the CJK reference font. Put differently, the one-step order lets the Latin reference font override the second font, while the two-step order lets the second font override the Latin reference. The same inputs can therefore produce different outputs depending on which route you take, which matters if the second font is a CJK face and the Latin reference is supposed to be a fallback rather than an authority. By default the completion tool uses two reference files, one for Latin text and one for CJK text, and the documentation notes that the operation diagram replaces both with fonts that better match the original style. The last step is packaging, where the prepared fonts are dragged onto the packaging script and the resulting Fonts folder is moved into the World of Warcraft retail client directory. ## macOS refuses unsigned binaries until you open them once The macOS and Linux workflows differ from Windows in a way that catches people out. On recent macOS versions, unsigned applications are not allowed to run by default, and the documentation therefore asks you to run each relevant program once manually, by holding Control and clicking it, choosing Open in the menu, and closing the window afterwards. The program fails at that point because of a missing argument, and the documentation says not to worry about the error. The list of programs to do this with covers the whole toolchain: merge-otd, otfccdump, otfccbuild, and whichever of the command scripts you intend to run, which on macOS are .command files and on Linux are .sh files. After that, the usage itself is a prompt-driven flow rather than a drag and drop. You open the corresponding .command or .sh file, then follow the prompts, dragging the font files into the command window and pressing Enter to confirm. After a short wait the completed font out.ttf appears. The result is the same out.ttf as on Windows, produced by the same three executables, just reached through a different interface. The macOS gate exists because the binaries are not signed, and the workaround is per binary rather than a single system setting, which is why the documentation lists each program by name. ## The pipeline is otfccdump, merge-otd, otfccbuild Underneath the scripts, the toolchain is a three-step pipeline built on otfcc, and the documentation gives the commands for it. Each input font is dumped to an intermediate .otd file, the .otd files are merged, and the result is built back into a TrueType file. The build itself is CMake based. ```bash cmake . -B build/ -DCMAKE_BUILD_TYPE="Release" cmake --build build/ -j ``` The build directory is then put on the PATH so the three executables can be found, and the sequence is dump the Latin font, dump the CJK font, merge them with merge-otd, and rebuild with otfccbuild using the -O2 optimisation flag before removing the intermediate .otd files. The same sequence handles the completion case, with three dumps instead of two: the font to be completed, a comprehensive Latin font, and a comprehensive CJK font, all merged into one base and rebuilt. Two extra capabilities are documented. merge-otd can be given a font name with the -n option, taking a semicolon separated list of style names such as regular, bold, extended and italic, which is how a merged family keeps its style variants. And the number of fonts merged in one go is limited in principle only by the underlying constraints, with the documentation naming the command line argument limit, memory and the number of characters in the OpenType table. The example in the documentation merges eight fonts covering basic and extended Latin, Greek, Cyrillic, kana, basic and extended Han, Hangul and other CJK symbols. Merging everything in one command is a deliberate choice. The .otd intermediate format means the expensive dump and build steps happen once per file, and the merge is then a cheap operation on already parsed data. ## No 32-bit build and no multithreading, by stated design The limitations section is specific and does not hedge. There is no prebuilt 32-bit version, for three reasons. A 32-bit operating system generally cannot meet the memory requirements of the tool. Running a 32-bit build on a 64-bit operating system is very likely to exceed the 4 GiB per process memory limit. And for Windows ARM64 the project ships a native version, so a 32-bit build is no longer needed there for compatibility. A packaging script for Windows x86 still exists, and the documentation says 32-bit support may be removed entirely in future. Multithreading is not supported yet. The reasoning is that otfcc was originally a development tool that could use multitasking to make full use of a multi-core processor, and the project expects to support that gradually, but with no clear timetable. Both limitations point the same way. This is a tool for a single user merging a handful of fonts on a desktop, not something to run on a build farm processing thousands of font files in parallel. The 20 second figure the documentation gives for a Chinese and English merge sits comfortably inside that expectation. The credit list also explains where the hard parts came from. The otfcc programs for parsing and generating OpenType files come from caryll, the JSON interface comes from nlohmann's json library, in a modified version of json.hpp that tolerates characters with non-standard encodings, which matters for CJK text. The TrueType and PostScript curve conversion algorithms come from AFDKO and Fontello, with standalone versions for otfcc in a separate repository that allow OpenType/TT and OpenType/CFF fonts to be converted into each other. Boost.Nowide and clipp provide the cross platform command line handling. ## MIT licensed, with releases that lag the source The licence is MIT, with a LICENSE file at the root of the repository and a README_JP.md alongside the main README for Japanese readers. The maintenance picture needs reading carefully. The last release was v1.1.0 on 2022-06-04, and before that v1.0.0 on 2020-03-27 and v0.3.3 on 2019-06-27. The last push was on 2026-08-13 and the repository is not archived, so the source has moved on considerably since the newest published binary. That gap is the thing to plan around. A player who downloads the latest release gets code from June 2022, while the repository contains four years of later work that is not in any release archive. The build system is CMake with a CMakeLists.txt at the root, and the repository is split into the expected parts: src/ for the C sources, include/ for headers, font/ and font-builder/ for the font tooling, config/, script/ and package/ for the packaging pipeline, and image/ for the documentation screenshots. There is a .clang-format file, so the code is formatted with clang-format. The documentation also points at the package directory for anyone who wants to publish their own modified version, with instructions and scripts there, which is the path to take if you need a change that has not been released. ## Conclusion Use Warcraft Font Merger if you are replacing the fonts in a World of Warcraft client and your Latin and CJK faces come from different sources, because merging them alone leaves characters missing and this tool fills the gaps from bundled reference fonts. Do not use it if you need 32-bit Windows support, which is not provided and may be removed, or if you need multi-core speed on very large font sets, since threading is not implemented. Before packaging, compare a one-step merge against a two-step merge on your own files, because the documented glyph priority order differs between the two workflows. ## FAQ ### What does the Warcraft Font Merger tool actually do? It merges two fonts and completes the result so that missing characters are filled in from reference fonts, producing a single out.ttf. It can also complete a font on its own and generate a font package for the World of Warcraft client. ### Which platforms does Warcraft Font Merger support? It ships 64-bit builds for Windows x64, Windows ARM64, macOS and Linux amd64. The macOS build needs macOS 10.15 or later and is a universal binary, and there is no prebuilt 32-bit version. ### What is the difference between the XS, SC and CL bundled font sets? XS is a compressed font set covering GBK plus Korean Hangul, SC covers GB18030 plus Korean Hangul and is the recommended set, and CL also covers GB18030 plus Korean Hangul but uses glyph shapes closer to traditional printing. ### Does merging and completing in one step differ from doing it in two steps? Yes. In one pass the glyph priority is the first font, the Latin reference font, the second font and the CJK reference font, while in two passes it is the first font, the second font, the Latin reference font and the CJK reference font. ### Why will the tool not run on my Mac? Recent macOS versions do not allow unsigned applications to run by default. Hold Control and click the program, choose Open in the menu, and close the window, repeating this for merge-otd, otfccdump, otfccbuild and the command file you want to use. ### How do I build Warcraft Font Merger from source? Use CMake with cmake . -B build/ -DCMAKE_BUILD_TYPE="Release" followed by cmake --build build/ -j, then put the build directory on the PATH so the executables can be found. The instructions for publishing a modified build are in the package directory. ## Sources - [Issues](https://github.com/nowar-fonts/Warcraft-Font-Merger/issues) - [License: MIT](https://github.com/nowar-fonts/Warcraft-Font-Merger/blob/master/LICENSE) - [nowar-fonts/Warcraft-Font-Merger on GitHub](https://github.com/nowar-fonts/Warcraft-Font-Merger) - [README](https://github.com/nowar-fonts/Warcraft-Font-Merger/blob/master/README.md) - [Releases](https://github.com/nowar-fonts/Warcraft-Font-Merger/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nowar-fonts-warcraft-font-merger