This is a test suite for text rendering engines. It is not easy to correctly display text, so we founded this project to help implementations to get this right.
$ brew install cmake ninja npm rust
$ git clone --recursive https://github.com/unicode-org/text-rendering-tests.git
$ cd text-rendering-tests
$ for engine in CoreText FreeStack TehreerStack fontkit OpenType.js Allsorts ; do python3 check.py --engine=$engine --output=reports/$engine.html ; doneCurrently, the test suite supports seven OpenType implementations:
-
With
--engine=FreeStack, the tests are run on the free/libre open-source text rendering stack with FreeType, HarfBuzz, FriBidi, and Raqm. These libraries are used by Linux, Android, ChromeOS, and many other systems. — Test report for FreeStack. -
With
--engine=CoreText, the tests are run on Apple’s CoreText. This option will work only if you run the test suite on MacOS X. — Test report for CoreText. -
With
--engine=TehreerStack, the tests are run on an open-source text rendering stack consisting of FreeType, SheenBidi, and SheenFigure. — Test report for TehreerStack. -
With
--engine=fontkit, the tests are run on fontkit, a JavaScript font engine. — Test report for fontkit. -
With
--engine=OpenType.js, the tests are run using OpenType.js, another JavaScript font engine. — Test report for OpenType.js. -
With
--engine=Allsorts, the tests are run using Allsorts, a parsing and shaping engine implemented in Rust. — Test report for Allsorts. -
With
--engine=Swash, the tests are run using Swash, a parsing, shaping, and scaling/rendering engine also implemented in Rust. — Test report for Swash.
It’s trivial to test other implementations; simply write a small wrapper tool:
-
For the Go font library, see here.
-
For the Rust font library, see here. You may be able to reuse (or factor out) the argument parsing and SVG-writing parts of the Swash test harness as a starting point.
The test cases are defined in the testcases directory. It contains HTML snippets which describe each test, and define the rendering parameters together with the expected result.
For each test case, the check.py script parses the HTML snippet to
extract the rendering parameters. Then, it runs a sub-process (written
in C++, Objective C, Rust or JavaScript depending on the tested
implementation) that writes the observed rendering in SVG format to
Standard Output. Finally, the script checks whether the expected
rendering matches the observed result. Currently, “matching” is
implemented by iterating over SVG paths, allowing for maximally 1 font
design unit of difference.
Copyright © 2016-2024 Unicode, Inc. Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in the United States and other countries.
A CLA is required to contribute to this project - please refer to the CONTRIBUTING.md file (or start a Pull Request) for more information.
The contents of this repository are governed by the Unicode Terms of Use and are released under LICENSE.