# PlemolJP: Japanese Programming Fonts with Fullwidth Space Detection

> PlemolJP combines IBM Plex Mono and IBM Plex Sans JP for code containing Japanese text. It offers four font families, eight weights, normal and italic styles, hidden-space and Nerd Fonts variants, with a custom licence that requires review.

**yuru7/PlemolJP** — IBM Plex Mono と IBM Plex Sans JP を合成したプログラミングフォント PlemolJP (プレモル ジェイピー)

- Repository: https://github.com/yuru7/PlemolJP
- Stars: 1,406 · Forks: 23
- Language: Shell
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/yuru7-plemoljp

## Why PlemolJP Combines Two Font Families

PlemolJP addresses a specific problem in Japanese programming environments: ASCII code and Japanese text often appear together, but one font family may not provide the desired shapes for both. The project combines IBM Plex Mono for the English-oriented side of the typeface and IBM Plex Sans JP for Japanese characters and related symbols. According to the README, the standard PlemolJP family uses IBM Plex Mono for ASCII letters, digits and symbols, while IBM Plex Sans JP supplies other Japanese characters and symbol sets.

The intended audience is developers who work with code containing Japanese text, especially people who need a predictable distinction between halfwidth and fullwidth characters. The README says that accidental fullwidth spaces are a common source of trouble in Japanese programming environments. PlemolJP therefore modifies the default archive so that a fullwidth space is visible instead of disappearing into the text.

This is a font, not a source-code analyzer. It cannot explain why a fullwidth space entered a file, prevent the insertion, or repair the affected line. It gives the developer a visible clue during review. That distinction matters when evaluating the project: the font addresses recognition at the point of reading, not validation at the point of input.

## Inside PlemolJP's Four Family Choices

PlemolJP is organized into four font families, each representing a different compromise between Latin glyph design, symbol width and screen density.

The regular `PlemolJP` family follows a halfwidth 1 to fullwidth 2 width ratio. It applies IBM Plex Mono forms mainly to ASCII letters, numbers and symbols, then uses IBM Plex Sans JP for Japanese characters and other symbols. This is the conventional choice when a two-to-one width relationship is expected.

`PlemolJP Console` does not remove the IBM Plex Mono glyph treatment when assembling the family. The README specifically points to arrows and many other symbols becoming halfwidth, making this family appropriate for consoles and users who want eligible symbols displayed within the narrower width. The trade-off is that this family is not simply a more compact copy of the standard family. Its symbol policy differs deliberately.

`PlemolJP35` changes the regular family's relationship to halfwidth 3 and fullwidth 5. Its English letters and numbers appear larger than in regular `PlemolJP`, and the README suggests it for documents or code containing relatively little Japanese. `PlemolJP35 Console` applies the same 3:5 relationship to the Console design. The choice therefore involves two separate axes: whether Console symbol treatment is retained and whether the text uses a 3:5 rather than a 1:2 ratio.

The README shows eight weights for each style: Thin, ExtraLight, Light, Regular, Text, Medium, SemiBold and Bold. Normal and italic styles are supported in line with the IBM Plex Mono series. This gives editors several visual weights without requiring separate font families for each weight, although the README does not provide editor-specific installation or configuration commands.

## Choosing the PlemolJP Release Archive

The documented starting point is the latest GitHub Releases page. The README links directly to it and presents the download as the normal way to obtain the font. It does not provide installation commands, so there is no verified package manager or platform-specific command to reproduce here. A separate document named `doc/install_via_homebrew.md` is linked for Homebrew installation on Mac, but the README does not state its commands or describe its setup procedure.

Release assets also determine one important behavior. The default archive includes the fullwidth-space visualization modification. Users who do not want that treatment are directed to select an archive whose name follows this pattern:

```text
PlemolJP_HS_vx.x.x.zip
```

`HS` means `Hidden Space` in the README. The version portion is represented there as `x.x.x`, so a reader must use the actual number shown on the release page rather than type the placeholder. This archive is the relevant choice when hidden fullwidth spaces are acceptable or when the visible modification is undesirable.

For terminals and development environments that use Powerline symbols and other Nerd Fonts glyphs, the README points to a different asset pattern:

```text
PlemolJP_NF_vx.x.x.zip
```

`NF` means `Nerd Fonts`. The README does not enumerate the included glyphs, patch level, supported Nerd Fonts version or font names inside the archive. As a result, selecting `NF` based on the archive label is documented, but assuming a particular patch compatibility would not be supported by the README.

## A First PlemolJP Setup Without Repository-Specific Commands

A first use starts by choosing one family rather than installing every release variant. For a mixed Japanese code editor where a conventional 1:2 layout is required, `PlemolJP` is the direct starting point. For a console dominated by arrows and symbols, inspect `PlemolJP Console` because its documented behavior keeps IBM Plex Mono treatment and makes more eligible symbols halfwidth. For Japanese-light code where the README expects larger English characters, inspect `PlemolJP35` or `PlemolJP35 Console`.

Next, choose the archive behavior. Use the normal release asset when the visible fullwidth-space indication is wanted. Choose the asset named with `_HS_` when spaces should remain hidden. Choose `_NF_` only when Nerd Fonts or Powerline symbols are required.

The README does not document operating system installation directories, font configuration paths, editor commands, fontconfig settings or terminal commands. It would therefore be misleading to supply a `cp` command, a shell command or an editor setting that the repository does not document. After downloading the selected archive, use the installation procedure provided by the target operating system or application, then configure the exact installed family name through that application's font selector.

The first useful inspection should contain an ASCII line, Japanese text, an arrow or console symbol where relevant, an italic sample and the preferred weight. Include a fullwidth space in a harmless test string when using the default archive. Its visibility is the feature to verify. Do not treat a successful font preview as proof that line-height, terminal cell behavior or editor ligatures meet your expectations, because the README does not document those settings.

## Repository Scripts and the Font Build Surface

Based on the repository layout, the source distribution is more substantial than a repository containing only finished font files. Top-level entries include `build.ini`, `fontforge_script.py`, `fonttools_script.py`, `check_generated_fonts.py`, `source/`, `hinting_post_process/`, `work_scripts/` and `old_script/`. Build entry points also include `make.sh` and `make.ps1`, while `release.sh` sits beside the font-generation and checking files.

The presence of both `fontforge_script.py` and `fonttools_script.py` shows that the build workflow is divided between font manipulation tooling, but the README does not describe their exact order or responsibilities. It points contributors to `HOW_TO_BUILD.md` rather than reproducing build commands.

The repository includes generated-output checking through `check_generated_fonts.py`, as indicated by the file name and its placement beside the build configuration. That suggests output validation is part of the project structure, but the README does not state what properties the script checks or what constitutes a passing result. Contributors should consult `HOW_TO_BUILD.md` for prerequisites, exact commands and output locations.

The directories `bak/`, `old_script/` and `work_scripts/` indicate retained historical or working material. Their presence may help maintainers trace earlier generation logic, but it also makes the current build path less obvious to a new contributor. The README does not identify which old scripts remain necessary or which files are inputs to a current release.

## PlemolJP Limits, Alternatives and Licence Review

The clearest limitation is that PlemolJP offers font-level visibility for accidental fullwidth spaces, not input prevention or source validation. Code can still contain the wrong character, and the visible treatment may still be inconvenient when fullwidth spaces have a deliberate purpose. Users who prefer the unmodified spacing behavior can select the `_HS_` release, but that removes the feature rather than adding another way to diagnose the character.

Width compatibility is another boundary. The standard families use halfwidth 1 to fullwidth 2, while the `PlemolJP35` families use 3:5. That is a meaningful design choice for mixed Japanese documents, but the README does not claim compatibility with any particular terminal emulator, editor or display resolution. Applications that handle monospaced metrics differently may require their own verification.

A real alternative listed by the README is `HackGen`, which combines `源柔ゴシック` for Japanese characters with `Hack` for the English portion. The difference is compositional: PlemolJP joins IBM Plex Mono and IBM Plex Sans JP, whereas HackGen joins a different Japanese face and Hack. The repository also lists `Firge`, using `源真ゴシック` with `Fira Mono`, and `UDEV Gothic`, using `BIZ UDゴシック` with `JetBrains Mono`. These alternatives allow a developer to compare source font combinations, although the README does not provide their licensing, metrics, weights or terminal behavior.

The repository is not archived, and the last push was on 2026-08-10. Release `v3.1.0` was also published on 2026-08-10. That establishes a recent repository state, but upgrade cost still depends on the custom `LICENSE`. GitHub classifies the licence as custom, and the README does not summarize redistribution, embedding, modification or commercial-use terms. Review `LICENSE` directly for those conditions. This is a licence-reading requirement, not legal advice.

## PlemolJP v3.1.0 Upgrade Considerations

The latest listed release is `v3.1.0`, dated 2026-08-10. It follows `v3.0.0` from 2025-06-28 and `v2.0.4` from 2025-04-02. The release list does not provide individual change notes, migration instructions or compatibility statements, so it does not support claims about the contents of the version jump.

Upgrading normally means obtaining the new release asset and selecting it again through the operating system or editor. Because PlemolJP has multiple families, weights, styles and archive variants, an upgrade can require removing or replacing the installed family names for every variant the user previously deployed. The README does not state whether old font files remain installed, whether a package manager handles replacement, or whether there are conflicts with older versions. Those points require local verification.

The repository's Shell entry point and build files indicate that release production may involve scripted font generation, but the README directs developers to `HOW_TO_BUILD.md` for the build process. Contributors should not treat the release archive as a substitute for the source workflow, and application users should not need to run `make.sh` merely to install a published font.

Before replacing an existing installation, record which of the four families and which archive variant are in use. Keep a copy of any custom `fontconfig` or application configuration outside the font files themselves. The repository does not document such configuration, so the safe scope of this advice is limited to checking the actual installed family names and the selected `_HS_` or `_NF_` release type.

## Conclusion

Developers who routinely read mixed Japanese and ASCII code should inspect PlemolJP's four families, choose the correct standard, Hidden Space or Nerd Fonts archive, and review the custom LICENSE first. Projects that require documented redistribution terms or a proven licensing model should not adopt it until that file answers those questions. The first verification is whether the selected family's width ratio and visible fullwidth-space treatment match the target editor or terminal.

## FAQ

### Which PlemolJP family should I use for Japanese programming?

Use `PlemolJP` for the documented halfwidth 1 to fullwidth 2 layout. Consider `PlemolJP Console` when narrow symbols and console use matter, or the `PlemolJP35` families when the 3:5 layout is preferred.

### Does PlemolJP show accidental fullwidth spaces?

Yes. The normal release modifies the font so that fullwidth spaces are visible. The `_HS_` release is the Hidden Space variant for users who do not want that visualization.

### Which PlemolJP download includes Nerd Fonts symbols?

Select the release asset whose name follows `PlemolJP_NF_vx.x.x.zip`. The README identifies this as the Nerd Fonts version and says it includes Powerline symbols and related glyphs.

## Sources

- [Issues](https://github.com/yuru7/PlemolJP/issues)
- [README](https://github.com/yuru7/PlemolJP/blob/main/README.md)
- [Releases](https://github.com/yuru7/PlemolJP/releases)
- [yuru7/PlemolJP on GitHub](https://github.com/yuru7/PlemolJP)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yuru7-plemoljp