# Fusion-JetBrainsMapleMono: two fonts, four variants, and a version scheme that is not one to one > The README reports a check time hours after the last push and months after the last release. The version numbers encode two upstreams at once, which is where most downloads go wrong. **SpaceTimee/Fusion-JetBrainsMapleMono** — JetBrains Maple Mono: The free and open-source font fused with JetBrains Mono & Maple Mono - Repository: https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono - Stars: 2,286 · Forks: 48 - Language: Python - License: OFL-1.1 - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/spacetimee-fusion-jetbrainsmaplemono ## What a fusion project actually has to solve The premise is simple to state and hard to satisfy. JetBrains Mono is a well-liked programming font with excellent Latin glyphs and no Chinese or Japanese coverage. Maple Mono is a monospace font that does cover Chinese and Japanese. Neither alone gives you a single font where a line of code and a line of prose both look deliberate in the same editor. The README's glyph section states the goal as Maple Mono filling in the CJK gaps JetBrains Mono leaves, with monospace sans-serif forms, high readability, and what it calls perfect 2:1 width alignment between Chinese and English. That ratio is the technical heart of the project. In a monospace font every Latin glyph advances by one unit. A CJK glyph is conventionally square, so it should advance by two units. If it advances by something else, a line containing CJK stops aligning with the lines above and below it, and column guides stop lining up. This is exactly the defect that makes bilingual monospace editing annoying, and it is why a fan fusion is worth building at all rather than just installing two fonts. The font ships under the SIL Open Font License 1.1, which permits embedding in applications and documents and permits redistribution provided the licence travels with it. The licence text is in the repository root, which matters more than it sounds: a font you cannot redistribute inside an application is not a font you can put in a product, and OFL is the licence that makes that possible. ## Four variants, and the one that defeats the purpose Every release archive is named with the same four-slot pattern, and reading it is the only setup step the project requires. ``` JetBrainsMapleMono-[NF/XX]-[NR/XX]-[NL/XX]-[HT/XX].zip ``` Each slot is either a two-letter code meaning the font has that feature, or the placeholder meaning it does not. There are four flags and they are independent, so the naming is four binary choices rather than one preset list. Nerd Font patches in glyphs for developer tools, terminals, and editors, and the README notes it makes the file slightly larger. This is the one most people want, because it is what puts file-type icons in a status bar. CN Narrow tightens the spacing around CJK glyphs. The README is explicit about the cost: it causes the 2:1 alignment between Chinese and English and between Japanese and English to stop being perfect. That is worth pausing on, because it means one of the four available variants is an explicit trade against the feature you are downloading the font for. If CJK alignment is your reason for using this font, you do not want this flag. It exists because some people prefer the tighter CJK spacing of the kind Maple Mono itself uses, and that is a legitimate preference, but it is a departure from the project's own headline. No Ligatures disables the smart ligature set, for anyone who finds those shapes distracting or has trouble telling a ligature from a sequence of characters. Hinted adds hinting instructions so the font renders more evenly on low-resolution screens at or below 1080p, at the cost of slightly softer rendering on high-resolution displays. The README's phrasing is that it may look a little blurred on high-resolution screens, which is the usual hinting trade and the reason it is a variant rather than the default. If you would rather not decide, the README names the answer directly: download the archive with the placeholder in all four slots. That is the plain build with none of the four modifications. ## The version number encodes two upstreams, so it is not a sequence This is the part that reliably confuses people, and it is visible in three release tags. The shared prefix is the giveaway. It is not a build counter that happens to be close together. The release notes spell out what each part means: the three most recent releases say they were fused with JetBrains Mono v2.304 alongside Maple Mono v7.7, v7.8, and v7.9 respectively. So the prefix encodes one upstream and the suffix encodes the other, and the numbers were chosen so the whole thing reads like a version. The JetBrains Mono release is v2.304, and the prefix is 1.2304. The Maple Mono release is a plain v7.N, and the suffix is 7N. Read that way, the three tags are not three steps of a progression. They are the same JetBrains Mono version fused with three different Maple Mono versions, published on 2025-09-13, 2025-12-04, and 2025-12-05 respectively. The two December releases one day apart tell you the author rebuilds when the Maple side moves even without any change on the JetBrains side. The practical consequence is about upgrades. If you are on 1.2304.79 and JetBrains Mono releases v2.305, you should expect a tag whose prefix changes, and everything after the first dot in the prefix moves with it. Conversely, a bump from 1.2304.79 to a hypothetical 1.2304.80 would mean a new Maple Mono and no new JetBrains Mono, which tells you nothing changed about the Latin glyphs you were reading code in. When you are deciding whether an update is worth reinstalling, that distinction is the entire question, and the tag alone does not answer it until you decode it this way. Each release note also records the specific workflow run that built it, which is the kind of provenance you wish more font projects provided. ## The README's own timestamp runs ahead of the last release The README has a section that reports when the project last checked its upstreams for updates, and it fills in two timestamps, one in Beijing time and one in UTC. Both read 2026-09-28, at 23:57:58 and 15:57:58. Those are the same moment, correctly offset by eight hours, which tells you the automation is working and formatting both correctly. The last push to the repository is 2026-09-28T15:58:00Z, which matches the UTC timestamp to within two seconds. So the most recent push was the timestamp update itself, produced by the scheduled job. Now put the newest release next to it. That is 1.2304.79, published 2025-12-05. So the checker has run and updated the README on a schedule, and the last time that check produced something was almost ten months before the most recent check ran. The README's feature list describes this as real-time updates with the whole build, fuse, optimise, and publish pipeline automated, and the script section says the checker looks for upstream releases and commits every five to thirty minutes and can be forced to skip the check and fuse anyway. That mechanism is real and it is running. What it has not done recently is produce a release, and the README does not claim it would. The tension is in the word real-time being applied to a pipeline whose output is a three-hour build plus publication, with the README itself noting that a full run takes about three hours. So there are two readings and the repository supports both. The generous reading is that the checker is deliberately quiet because neither upstream has released since December, and a working no-op is a working pipeline. The less generous reading is that the automation is running against a build that no longer succeeds. Nothing in the repository settles it, because the failure would be visible in the workflow runs rather than in any committed file. The actionable step is small and worth taking: open the repository's workflow runs and look at the most recent one. If it succeeded and found nothing new, you have your answer. If it failed, you know the pipeline needs attention before you trust the next build. Either way it is a thirty-second check, and it is the only way to tell those two readings apart. ## Five files, three tools, and a language field that is misleading The tree is the shortest in this batch, and it explains the whole build. ``` .github/ OFL.txt README.md fuse_fonts.ff strip_ligas.py ``` Five entries. A workflows directory, the licence, the README, a FontForge script file, and a Python script. There is no build system configuration, no source font files, and no upstream checkout mechanism committed to the tree. That tells you the fonts are not vendored. They are fetched by the workflow, from the two upstream repositories, at build time. Which is also why the tree can stay this small while the README describes a nine-step optimisation pass. The two script files map onto two different tools. The .ff extension is FontForge's native script format, and the filename says what it does, fusing the two fonts. The Python file strips ligatures, which is one of the four variant flags. So the pipeline is a FontForge fusion script plus a Python post-processing step, plus GitHub Actions to orchestrate. Here is a mismatch worth knowing about. The repository's language field is Python, which is accurate in the narrow sense that one of the two scripts is Python and it is the only language file in the tree. But the README describes the project as based on GitHub Workflows in Bash, and the fusion itself is a FontForge script in FontForge's own language. If you arrive expecting a Python codebase, you will be surprised, and the correct mental model is that the workflow is the project and the two scripts are the parts it runs. The optimisation list in the README is also more than a rebuild. It overwrites metadata, sets anchor point order, inserts instructions and hint information, adds extreme control points, cleans up outlines and starting points, removes redundant control points, rounds control point coordinates, and removes overlapping paths. Several of those steps exist to keep the font size down, which is why a Nerd Font build is described as slightly larger: the patched icons add glyphs on top of an already optimised base. The acknowledgements list four upstream projects rather than two. JetBrains Mono supplies all non-CJK glyph design and Maple Mono supplies all CJK glyph design, which is what the fusion description says. Resource Han Rounded and Source Han Sans are also credited with supplying the CJK base glyph design, which reaches further back, to the designs those two CJK families themselves derive from. Both accounts are true at different depths of the credit chain, and the four-project list is the more complete one. ## Editor setup, where most of the friction actually is Installing a font is the easy part. The README names two editor-specific settings, and both exist because this font is hinted. In Visual Studio you must set a text formatting method option to its ideal setting, in the advanced section of the text editor preferences, or rendering may look uneven. In VS Code you add one setting to enable ligatures, or remove it to disable them. ```json "editor.fontLigatures": true ``` The Visual Studio instruction is the more interesting of the two, and it is a consequence of the Hinted variant rather than an accident. A hinted font carries instructions that tell the rasteriser how to snap stems and curves to the pixel grid at small sizes. Those instructions produce even, readable text at 1080p and below, which is where the README says hinting helps. Visual Studio also has its own text formatting setting that interacts with font instructions, and when the two disagree you get the uneven rendering the README warns about. The editor's own setting wins, so you change the editor rather than download an unhinted build. That is the general lesson for this font. If you see uneven rendering somewhere and you installed a hinted build, look for a per-editor rendering setting before you switch variants, because switching variants changes the glyph outlines and hinting together and you lose the ability to isolate which one caused the problem. There is also CDN hosting, through a third-party font CDN, so you can reference the font by URL rather than installing it locally. That is convenient for shared machines and for previewing a variant before committing to it, and it is worth using for exactly that reason: with four independent flags and eight combinations, trying a variant from the CDN takes seconds and installing takes a restart. The downloads themselves come from two places on the repository's release page, one pointing at the latest release and one at a preview tag. The convention, spelled out in the README, is that a successful release build goes to latest and a build triggered by an upstream commit goes to preview. That mapping is genuinely useful: if you want the newest upstream glyphs and can accept a build that has not been announced, use preview, and if you want what the maintainer has pointed at, use latest. ## The roadmap tells you what will change in a filename Three items are listed as future work, and one of them has a direct effect on how you download the font today. Adding a variable weight version is first. Every current release is a set of static weights, which means picking an archive per weight and installing them as a group. A variable font would replace that with one file and a weight axis, which for a coding font is a real improvement because you can match the editor's weight rather than approximating it. Rebuilding directly on a rounded or a source sans CJK base is second, described as opening up more room for customisation, such as stroke end shapes and broader character coverage. That is the same thing Maple Mono did relative to the original design lineage, applied again. It is the deepest change on the list because it moves the CJK foundation rather than the fusion. Adding more font formats is third. The current builds are what they are, and more formats means more output for the same input. Read together, the roadmap says the fusion layer is stable and the base layers are what change. That is consistent with the version numbering, where the Maple suffix moves independently of the JetBrains prefix. It also means the practical advice for today does not change: read the four-slot filename, install the all-placeholder archive if you are unsure, and expect the JetBrains portion of the tag to move independently whenever that upstream releases. ## Conclusion Fusion-JetBrainsMapleMono is a good fit if you write code and read CJK in the same editor and cannot live with a fallback font changing your line rhythm. The 2:1 width alignment between Latin and CJK glyphs is the whole reason the project exists, and nothing else in the ecosystem delivers it as a single file you drop into a settings panel. Two things to get right before you download. Read the variant naming scheme carefully, because the four flags are independent and the defaults are not what most people want: Nerd Font adds icons, CN Narrow breaks the alignment you came for, No Ligatures disables smart ligatures, and Hinted trades sharpness at high resolutions for evenness at 1080p. If you are unsure, the README names the all-placeholder archive as the safe choice. Then read the version number as a pair rather than a sequence. The three most recent releases, 1.2304.77, 1.2304.78, and 1.2304.79, share the prefix that encodes the JetBrains Mono release and differ only in the Maple Mono release, so bumping the Maple side does not move the JetBrains side. ## FAQ ### Is Maple Mono a Nerd Font? Not by itself. Nerd Font is a patched build that adds icon glyphs for developer tools, terminals, and editors on top of an existing font. This project makes that available as a variant of the fusion, marked NF in the release filename, with the README noting it makes the file slightly larger. The NF slot is one of four independent flags, so you get it or you do not. ### What does Fusion-JetBrainsMapleMono actually fuse? JetBrains Mono and Maple Mono. The README credits JetBrains Mono with all non-CJK glyph design and Maple Mono with all CJK glyph design, and also credits Resource Han Rounded and Source Han Sans with the underlying CJK base glyph design. The fusion is performed by a FontForge script, with a Python step that strips ligatures for one of the build variants. ### How do I pick the right JetBrainsMapleMono download? Each archive is named with four slots, and each is either a feature code or a placeholder. NF adds developer icon glyphs, NR tightens CJK spacing but breaks the 2:1 alignment with Latin, NL disables ligatures, and HT adds hinting for even rendering at 1080p and below. If you are unsure, the README points you to the archive with placeholders in all four slots. ### What does the version number in the release tag mean? It encodes both upstreams rather than counting releases. The shared prefix 1.2304 corresponds to JetBrains Mono v2.304, and the suffix is the Maple Mono version, so 1.2304.77, 1.2304.78, and 1.2304.79 are all the same JetBrains Mono fused with Maple Mono v7.7, v7.8, and v7.9. A suffix bump means only the CJK side changed. ### How do I enable ligatures for JetBrainsMapleMono in VS Code? Add the font ligatures setting to your settings.json, or remove that line to turn them off. The README also notes a Visual Studio requirement: set the text formatting method option under advanced text editor settings to its ideal setting, or rendering can look uneven with the hinted build. ### How often does Fusion-JetBrainsMapleMono release new builds? The README says the workflow checks both upstreams for release and commit changes every five to thirty minutes and that a full build, fuse, optimise, and publish run takes about three hours. The most recent releases were published on 2025-09-13, 2025-12-04, and 2025-12-05, so the checks run often while releases appear only when an upstream moves. ## Sources - [Issues](https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono/issues) - [License: OFL-1.1](https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono/blob/main/LICENSE) - [README](https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono/blob/main/README.md) - [Releases](https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono/releases) - [SpaceTimee/Fusion-JetBrainsMapleMono on GitHub](https://github.com/SpaceTimee/Fusion-JetBrainsMapleMono) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spacetimee-fusion-jetbrainsmaplemono