ttf-parser — est une bibliothèque pour l'analyse des polices TrueType/OpenType.
La nouvelle version a ajouté un support complet des polices variables
(polices variables) et C API, c'est pourquoi j'ai décidé de la promouvoir sur le forum.
Jusqu'à récemment, s'il y avait besoin de travailler avec des polices TrueType, il y avait exactement deux options : FreeType et stb_truetype. Le premier est un énorme combine, le second prend en charge un nombre assez limité de fonctions.
ttf-parser se situe quelque part entre les deux. Il prend en charge toutes les mêmes tables TrueType (le format TrueType est constitué de nombreuses tables binaires distinctes) que FreeType, mais ne s'occupe pas de l'affichage des glyphes eux-mêmes.
Cependant, ttf-parser contient de nombreuses autres différences significatives :
- ttf-parser est écrit en Rust sans utiliser d'unsafe. FreeType et stb_truetype sont écrits en C.
- ttf-parser est la seule implémentation sécurisée (memory-safe). La lecture de mémoire arbitraire est impossible. FreeType corrige constamment les vulnérabilités, tandis que stb_truetype n'est pas destiné à lire des polices arbitraires.
- ttf-parser est la seule implémentation thread-safe. Tous les méthodes d'analyse sont constantes. La seule exception est la définition des coordonnées pour les polices variables, mais cette fonction est reentrant. FreeType est en principe mono-thread. stb_truetype — reentrant (vous pouvez utiliser des copies séparées dans différents threads, mais pas une seule des multiples).
- ttf-parser est la seule implémentation qui n'utilise pas d'allocation sur la 'heap'. Cela permet d'accélérer l'analyse et d'éviter des problèmes lors de l'OOM.
- De plus, presque toutes les opérations arithmétiques et les conversions de types numériques sont vérifiées (y compris statiquement).
- Dans le pire des cas, la bibliothèque peut lancer une exception. Dans l'API C, les exceptions seront capturées et la fonction renverra une erreur, mais ne plantera pas.
Et malgré toutes les garanties de sécurité, ttf-parser est également la réalisation la plus rapide. Par exemple, l'analyse de CFF2 est 3.5 fois plus rapide qu'avec FreeType. L'analyse de glyf est 10% plus lente qu'avec stb_truetype, mais c'est parce qu'il ne prend pas en charge les polices variables, pour lesquelles des informations supplémentaires doivent être stockées. Plus de détails dans README.
Source : linux.org.ru
