LXGW WenKai TC: a Traditional Chinese Kai face with inherited glyph forms

What makes this edition different from the original

LxgwWenkaiTC is the Traditional Chinese edition of LXGW WenKai, and the README describes its lineage in detail. It was originally built with AFDKO, the Adobe Font Development Kit for OpenType, working from inherited glyph and Kangxi old-form ttx files provided by a community user on a forum, a source the README notes is no longer reachable. Those files were used to convert the characters in Klee One into old forms, and old LXGW WenKai glyphs were added back in, with some components and individual characters then modified by hand. Later, most components were revised against the ichitenfont inherited-glyph standardisation document, which is what makes the result more suitable for Traditional Chinese readers and for people who prefer inherited glyph shapes. The practical upshot is that this is a font with a documented editorial process behind every component decision, not a mechanical conversion.

The standard is followed but not slavishly

The most important note in the repository is the one at the top, and it is a disclaimer rather than a boast. The glyph adjustments refer to the ichitenfont standardisation document, but they do not pursue complete compliance. Some components are deliberately traded off, and the ones named are the ones with many characters in common use, which were not changed according to the check table because the scale of the change would be too large. In addition, some components in the font use the common glyph shapes collected in that check table that are somewhat adjusted for visual reasons, with a list of specific examples given. The reasoning is legible: a standard is a guideline for consistency, but where consistency would require redrawing a very large number of characters, the author kept the familiar forms instead. The README says that if you disagree with these choices, Klee One is the alternative.

The variant-character merge is the trade you are making

The second important note explains a design decision that has real consequences for users. To raise coverage of inherited glyph forms, the font merges Unicode characters that are factually separate but which can be recognised as the same, with examples given of one being folded into another. The consequence is stated without hedging: the font is not suitable for contexts where those different glyph shapes need to be distinguished. This is the single thing to check before you adopt it. If your text contains a word where the two characters are semantically different and a reader must see the difference, this font will not let them. The README's advice in that case is to use Klee One, or a project derived from it. Merging is what buys the coverage, and coverage and disambiguation are in direct tension, so a project that quietly merged without saying so would be much harder to trust than one that documents it this clearly.

Character coverage, region by region

The coverage list is where the effort went, and it goes well beyond what a general Chinese font offers. Every character in the original Klee One font is included. So are the common characters from the Taiwan standard educational character table and the Hong Kong common character table, and every character in BIG5. The IICore range of 9810 characters is covered, along with the GB/T 12345-1990 and GB/T 2312-1980 standards for simplified and traditional forms, and the characters in the general standard character table together with their Traditional equivalents. Then there is the part that is unusual: common Cantonese, Min Nan and Hakka usage in the Hong Kong and Taiwan regions, organised by the supplementary character tables, from level A to C of the Hong Kong list through levels one to six, which cover very common Cantonese and variant characters, less common ones and other Cantonese forms, plus Taiwanese Min Nan and Hakka characters. The remaining characters come from LXGW WenKai Lite.

Unicode variation sequences for punctuation

The font supports Unicode Variation Sequences, which the README explains are used to choose the width and position of punctuation, with a table of the available options linked as a PDF in the documentation directory. This is a small feature that matters in practice for Chinese typesetting. CJK punctuation occupies a full em by default, and a comma at the end of a line in traditional Chinese typography is usually set as a half-width mark that hangs or sits differently depending on the convention you follow. Variation sequences let the renderer select the alternate form without needing a second font or a manual substitution, which means a document can carry both the full-width and the compact forms of the same punctuation and let the layout engine choose. It is the kind of detail that a general-purpose font usually skips and that a font built by someone typesetting Chinese daily tends to get right.

Building the fonts from source

The build runs through a Makefile with a virtual environment it manages itself. The dependencies are declared in requirements.txt, and they are the standard font toolchain: fontmake at 2.4 or newer, fontbakery at 0.7 or newer, gftools at 0.7 or newer, ufomerge and tzdata.

make build

The make help output describes the targets: build produces the fonts and places them in the fonts directory, test runs the fonts through fontbakery, and proof creates HTML proof documents in the proof directory. The build target chains the pipeline. It starts with extract, which runs sources/scripts/extract.py, then merge with sources/scripts/merge.py, then export, which invokes gftools builder against sources/project.yaml, and finally a Python step for post-processing. There is also a converter target that runs glyphs2ufo over six source files covering the light, regular and bold weights of both the main and the mono cuts, and a clean target that removes the virtual environment along with any ufo and pyc files. The README notes the source currently only runs on Unix-like systems and that Python 3 is needed.

What the author has ruled out, and why

A section lists the features that will not be supported, and the reasons are the interesting part because they explain the shape of the project. Variable fonts are ruled out because they require solving outline compatibility, node interpolation and weight axis design, a very large amount of work, and because the author lacks the experience of making variable fonts. Mark-to-base and mark-to-mark features are ruled out because they are mainly used to position combining marks, such as Latin diacritics and Indic conjuncts, and a Chinese body text face has no such requirement, while implementing them means writing extremely complex OpenType scripts that would significantly increase the font's complexity and rendering risk. Nerd icons are ruled out because that icon set targets monospaced programming fonts, and adding a large set of stylistically inconsistent icons would bloat the font file and bring a large maintenance cost. The README notes that there is a monospaced cut, but it supports only PowerLine symbols.

New characters are closed, and the licence is permissive

The notes section carries a decision that will frustrate some users and is worth knowing in advance. Glyph problems, uneven components and outline issues are reported in Issue 14, and the issue for requesting new characters is struck through and marked not to open a separate topic. The stated reason is that the font file is becoming increasingly bulky, and that after the v1.330 release the character-addition channel is temporarily closed and user requests for new characters will not be accepted. That is a policy about size rather than about effort, and it means the character set is fixed for now. The licence is the SIL Open Font License, with the OFL.txt file at the repository root, which is the permissive licence designed for fonts and allows embedding and redistribution with the reserved font name rules. The repository also carries AUTHORS.txt and CONTRIBUTORS.txt, a Makefile, requirements.txt, and the sources, fonts and documentation directories.

Editorial conclusion

Use LXGW WenKai TC when you need a readable Kai style face for Traditional Chinese text and your readers prefer the inherited or old glyph shapes, since the coverage spans the standard character lists, BIG5 and the regional Cantonese, Min Nan and Hakka usage that general fonts often miss. Do not use it where orthographically distinct characters must be told apart, because the project merges them deliberately, and it points you at Klee One for that case. Verify first that the build runs on your platform, since the source currently only runs on Unix-like systems and needs Python 3, that the merged characters do not appear in your text, and that the version you install is current, since the recent tags move fast and the character-addition channel has been closed since v1.330.

Frequently asked questions

Official sources

1. Issues
2. License: OFL-1.1
3. lxgw/LxgwWenkaiTC on GitHub
4. README
5. Releases