LXGW WenKai Lite is a trimmed WenKai cut to the size of an early release

The Lite edition exists for embedding, not for typographic preference

The README is direct about the reason this edition exists. It is provided so that developers can embed the font into software, with the character set sized to match that of an early version of LXGW WenKai, the release v1.008. As a trimmed version of the original WenKai font, it removes some of the less commonly used Chinese characters and Korean characters that the full edition added, and it is suitable for embedding in apps.

That framing matters, because there is a second sentence that changes how the editions relate. If the full edition has glyph optimisations or feature updates, the Lite edition will follow. So this is not a frozen artefact that will drift away from the main font; it tracks it, with the character set as the only thing held back.

The character list is where the engineering decision becomes concrete, and the README breaks it into tiers with different priority marks. The first tier covers the simplified forms corresponding to the traditional characters in the original character set, limited to the GBK range, then 3603 common simplified Chinese characters covering both the old 3500-character table of common modern Chinese and the newer 3500-character list from the compulsory education curriculum, then 6763 characters from GB/T 2312-80, then 8105 characters from the standard table of general Chinese characters, then 7079 characters from the Chinese mainland standard telegraph codebook, and the characters outside the Xiahe input method table.

The second tier adds traditional and regional coverage: 6866 characters from GB/T 12345-90, 4808 common traditional characters from the Taiwan standard font list, the Hong Kong common character table including some variant forms, all 13060 BIG5 characters, the traditional column of the standard-to-traditional comparison table, and the Cantonese, Min Nan and Hakka characters used in Hong Kong and Taiwan regions, drawn from an external supplementary character table and graded from A to C and 1 through 6 plus the rarer levels.

The third tier adds characters from the Hanyi and Founder simplified and traditional foundry lists, 9810 characters in the IICore range, dialect, personal name, place name and academic rare characters from the irg project, and the traditional and variant forms already entered under the U initial in the Xinhua Dictionary and the Modern Chinese Dictionary.

A reader choosing between the two editions is really reading that list and deciding which tier their text needs.

Unicode variation sequences decide punctuation width and position

One feature in the README stands out because fonts rarely mention it and it changes how text looks. The GB edition of the font, referred to as LXGW WenKai GB Lite, supports Unicode Variation Sequences, used to choose the width and position of punctuation marks, and a documentation file at documentation/uvs.pdf lists the available mappings.

The mechanism is worth understanding at a level above the font, because it is how a family handles full-width and half-width punctuation in the same run of text. Chinese typography has two conventions for certain punctuation, one that occupies a full em and one that occupies half, and the choice depends on context: a comma at the end of a clause in running text is conventionally narrow, while a comma in a list or a title is conventionally full-width. A font can only express both by shipping both glyphs and letting the text select between them.

Unicode variation sequences are how that selection is expressed in the character stream. A base character followed by a variation selector picks a specific glyph, and the font supplies the alternate. That means the behaviour is decided by the text, not by the layout engine's heuristics, which is why the family ships a table of them.

The same mechanism is what allows a font to expose alternate stylistic forms that are not simply a different weight, and it is the reason a family with several members can offer several designs under one family name without a separate font file per design.

For an embedder this has a practical consequence. The variation sequences only work if the text actually contains them, so any content pipeline that normalises or strips variation selectors will lose the punctuation behaviour. The PDF is the reference to consult when you need to know which characters carry a sequence and what the alternatives look like.

Building from source means a submodule, a virtualenv and Python tooling

The README gives two ways to get the font. The first is to download the ttf format font files from the Releases page, or to take them from the fonts/TTF folder in the repository. Two mirrors, one on YS E drive and one on Lanzou cloud with the password 8ppk, are said to update within 24 hours of a GitHub project update.

The second is to build it. The build runs with make, using the target make build, and the README is precise about the constraints: the source code depends on the submodule LxgwWenKai-Shared, it can only run on Unix-like systems, and Python 3 has to be installed.

The Makefile shows how small the orchestration actually is. There are four targets and a help text:

venv/touchfile: requirements.txt
build: venv merge export

The venv target creates a virtualenv only if it does not already exist, installs the requirements, and touches a marker file so the environment is not rebuilt on every make invocation. The merge target runs the shared project's build script, export runs gftools builder against sources/project.yaml, and the build target adds a post-processing step. The clean target removes the virtualenv and any ufo or pyc files left behind.

The requirements are the standard font toolchain:

fontmake>=2.4
fontbakery>=0.7
gftools>=0.7
ufomerge
tzdata

fontmake compiles the sources, fontbakery checks them, gftools exports the final binaries, and ufomerge merges the Unifont pieces that cover the non-Han glyphs. tzdata is there because timezone data has to be available at build time for the font tables.

The repository layout supports this: a sources directory with the build scripts and a project.yaml, a fonts directory for the output, a documentation directory for the UVS table and the preview images, and a requirements.txt at the root. There is also an OFL.txt, which the licence section says must accompany any redistribution.

The primary language of the repository is recorded as Shell, because the entry point is the Makefile and the shared build scripts.

The OFL terms restrict names and bundling, and the README quotes them

The font is licensed under the SIL Open Font License 1.1 and is derived from Klee, an open source project developed and published by FONTWORKS, now Monotype KK. Klee is a FONTWORKS trademark. The original font's designer is Francis Chow, and the README credits a list of people who gave guidance on glyph design and helped run the project.

The licence section spells out what an embedder can do. The font can be used freely, personally or commercially, with no fee and no need to notify the author. It can be freely distributed and shared, installed on a system, embedded in software or apps, and bundled with any software for redistribution or sold together, provided the redistribution includes the full text of OFL.txt. It can be freely modified, with derived fonts required to follow the same OFL 1.1 terms and conditions.

The restrictions are where a project with a brand needs to read carefully, and the README cites the specific clauses. Under clause 1, selling the font files on their own, in OTF or TTF format, is forbidden. Under clause 3, a derived font cannot use the original font's reserved names without the author's explicit written permission, and the reserved names here are LXGW, and the two Chinese names for the project and for the phrase the full font is named after. A recompiled font with no change to the source is treated as an exception and may keep the name, as is a subset or format conversion made purely for web rendering, such as WOFF or WOFF2, provided it is not offered to the public as an installable desktop font file, which covers mainstream web font hosts and the third party platforms the author recognises. Other platforms wanting that exception are asked to contact the author first. Under clause 4, no derived font may be promoted, endorsed or advertised in the author's name without explicit written permission.

Clause 5 is the one that catches packaging teams. The font may not be distributed under a licence other than OFL 1.1, and it may not be merged into the same font file as fonts under potentially conflicting licences such as the GNU GPL or the IPA font licence.

There is also a note that a Simplified Chinese translation of the OFL 1.1 is available from a third-party site for convenience, and that it is unofficial and for reference only. The English text is what governs.

Two practical notes about naming and character coverage

The README's notes section carries two items that affect an embedding project directly.

The first is naming. The font can coexist with the full WenKai edition, and its family name in a Simplified Chinese environment is the Chinese name with the Lite suffix, while in other language environments it is LXGW WenKai Lite. If your application ships both the full edition and the Lite edition, the two must not be installed with the same family name, and the naming difference the README describes is what keeps them apart. It is worth checking that the family name your application asks for matches the environment it will run in, because the same font file resolves to a different name depending on the language setting.

The second is coverage. Because this is the trimmed edition, it is missing some relatively uncommon Chinese characters within the GB 18030-2022 implementation level 2 scope, and for text that specifically needs those characters the README directs you to the full edition. This is the boundary of the whole project, stated plainly: the Lite edition is for embedding, and if your corpus contains characters outside the tiers listed earlier, the answer is the other repository.

The release history shows how actively the subset is maintained. The recent releases are v1.530 dated 18 October 2026, v1.530-RC dated 13 October 2026, and v1.522 dated 17 March 2026, and the last push to the repository was on 2026-10-18. The version numbers track the full edition's numbering, which is consistent with the promise that the Lite edition follows the full edition's glyph optimisations and feature updates.

For a project that embeds the font in an application, the practical decision is a size-versus-coverage calculation. The Lite edition cuts the character set to fit an application bundle; the coverage list tells you whether your own text stays inside that cut, and the release cadence tells you the cut will move as the full font gains characters.

Editorial conclusion

Adopt LXGW WenKai Lite if you are embedding a Chinese typeface inside an application and the full WenKai file is too large to ship, since this edition is deliberately cut to the character footprint of an early release while keeping the common characters, the traditional forms and the punctuation variation sequences. Do not adopt it if your text contains rare characters, because the README states that within the GB 18030-2022 implementation level 2 scope the font is missing a number of uncommon hanzi and points you to the full edition instead. Verify first that the reserved names are not a problem for you, since the OFL 1.1 terms bar derivatives from using the name unless the author gives written permission, that you are on a Unix-like system with Python 3 if you intend to build from source rather than download a release, and that any redistribution carries the full OFL.txt text.

Frequently asked questions

Official sources

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