Text rendering tests
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 python check.py --engine=$engine --output=reports/$engine.html ; doneSupported Platforms
Currently, the test suite supports six 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.
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.
Test Cases
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 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.
Contributing
Your contributions are very welcome; simply send pull requests via GitHub. A bot will ask you (on the GitHub review thread) to accept Unicode’s Contributor License Agreement by clicking on a web form. Alternatively, if you prefer paper, you can also send a signed paper copy of the agreement to Unicode.