Repository files navigation

This is a test suite for text rendering engines. It is not easy to correctlydisplay text, so we founded this project to help implementations toget this right.

$ brew install cmake ninja npm rust$ git clone --recursive https://github.com/unicode-org/text-rendering-tests.git$cd text-rendering-tests$forenginein CoreText FreeStack TehreerStack fontkit OpenType.js Allsorts;do python3 check.py --engine=$engine --output=reports/$engine.html;done

Currently, the test suite supports seven OpenType implementations:

• With--engine=FreeStack, the tests are run on the free/libreopen-source text rendering stack withFreeType,HarfBuzz,FriBidi,andRaqm. These librariesare 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-sourcetext rendering stack consisting ofFreeType,SheenBidi, andSheenFigure.—Test report for TehreerStack.

• With--engine=fontkit, the tests are run onfontkit, a JavaScript font engine.—Test report for fontkit.

• With--engine=OpenType.js, the tests are run usingOpenType.js, another JavaScript font engine.—Test report for OpenType.js.

• With--engine=Allsorts, the tests are run usingAllsorts,a parsing and shaping engine implemented inRust.—Test report for Allsorts.

• With--engine=Swash, the tests are run usingSwash,a parsing, shaping, and scaling/rendering engine also implemented inRust.—Test report for Swash.

It’s trivial to test other implementations; simply write a small wrappertool:

• For theGo fontlibrary, seehere.

• For theRust font library, seehere. You may be able toreuse (or factor out) the argument parsing and SVG-writing parts of theSwash test harness as a starting point.

The test cases are defined in thetestcases directory.It contains HTML snippets which describe each test, and define therendering parameters together with the expected result.

For each test case, thecheck.py script parses the HTML snippet toextract the rendering parameters. Then, it runs a sub-process (writtenin C++, Objective C, Rust or JavaScript depending on the testedimplementation) that writes the observed rendering in SVG format toStandard Output. Finally, the script checks whether the expectedrendering matches the observed result. Currently, “matching” isimplemented by iterating over SVG paths, allowing for maximally 1 fontdesign 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 theCONTRIBUTING.md file (or start a Pull Request) for more information.

The contents of this repository are governed by the UnicodeTerms of Use and are released underLICENSE.