Il s'agit d'une suite de tests pour les moteurs de rendu de texte. Il n'est pas facile d'afficher correctement le texte, nous avons donc fondé ce projet pour aider les implémentations pour bien faire les choses.
$ 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 ; done Actuellement, la suite de tests prend en charge six implémentations OpenType:
Avec --engine=FreeStack , les tests sont exécutés sur la pile de rendu de texte Open-source libre / libre avec Freetype, HarfBuzz, Fribidi et Raqm. Ces bibliothèques sont utilisées par Linux, Android, Chromeos et de nombreux autres systèmes. - Rapport de test pour Freestack.
Avec --engine=CoreText , les tests sont exécutés sur CoreText d'Apple. Cette option ne fonctionnera que si vous exécutez la suite de tests sur MacOS X. - Rapport de test pour CoreText.
Avec --engine=TehreerStack , les tests sont exécutés sur une pile de rendu de texte open source composée de freetype, de sheenbidi et de sheenfigure. - Rapport de test pour Tehreerstack.
Avec --engine=fontkit , les tests sont exécutés sur Fontkit, un moteur de police JavaScript. - Rapport de test pour Fontkit.
Avec --engine=OpenType.js , les tests sont exécutés à l'aide d'OpenType.js, un autre moteur de police JavaScript. - Rapport de test pour OpenType.js.
Avec --engine=Allsorts , les tests sont exécutés à l'aide de Allsorts, un moteur d'analyse et de mise en forme implémenté en rouille. - Rapport de test pour ALLSORTS.
Il est trivial de tester d'autres implémentations; Écrivez simplement un petit outil d'emballage. Pour la bibliothèque de police Go, voyez ici. Pour la bibliothèque de polices de rouille, voyez ici.
Les cas de test sont définis dans le répertoire de tests de test. Il contient des extraits HTML qui décrivent chaque test et définissent les paramètres de rendu avec le résultat attendu.
Pour chaque cas de test, le script check.py analyse l'extrait HTML pour extraire les paramètres de rendu. Ensuite, il exécute un sous-processus (écrit en C ++, objectif C, Rust ou JavaScript en fonction de l'implémentation testée) qui écrit le rendu observé au format SVG à la sortie standard. Enfin, le script vérifie si le rendu attendu correspond au résultat observé. Actuellement, la «correspondance» est implémentée en itérant sur les chemins SVG, permettant une unité de conception de police maximale 1 de la différence.
Copyright © 2016-2024 Unicode, Inc. Unicode et le logo Unicode sont des marques déposées d'Unicode, Inc. aux États-Unis et dans d'autres pays.
Un CLA est tenu de contribuer à ce projet - veuillez vous référer au fichier contributing.md (ou démarrer une demande de traction) pour plus d'informations.
Le contenu de ce référentiel est régi par les conditions d'utilisation UNICODE et est libéré sous licence.