analizador-ttf es una biblioteca para analizar fuentes TrueType/OpenType.
La nueva versión tiene soporte completo para fuentes variables.
(fuentes variables) y C API, como resultado de lo cual decidí anunciarlo en la historia.
Hasta hace poco, si era necesario trabajar con fuentes TrueType, había exactamente dos opciones: FreeType y stb_truetype. La primera es una cosechadora enorme, la segunda admite una cantidad bastante pequeña de funciones.
ttf-parser está en algún punto intermedio. Admite las mismas tablas TrueType (el formato TrueType consta de muchas tablas binarias separadas) que FreeType, pero no dibuja los glifos en sí.
Al mismo tiempo, ttf-parser contiene muchas otras diferencias importantes:
- ttf-parser está escrito en Rust sin utilizar unsafe. FreeType y stb_truetype están escritos en C.
- ttf-parser es la única implementación segura para la memoria. No es posible leer la memoria aleatoria. Las vulnerabilidades se corrigen constantemente en FreeType y, en principio, stb_truetype no está diseñado para leer fuentes arbitrarias.
- ttf-parser es la única implementación segura para subprocesos. Todos los métodos de análisis son constantes. La única excepción es establecer coordenadas para fuentes variables, pero esta función es reentrante. FreeType es básicamente de un solo subproceso. stb_truetype: reentrante (puedes usar copias individuales en diferentes hilos, pero no una de muchas).
- ttf-parser es la única implementación que no utiliza asignaciones de montón. Esto le permite acelerar el análisis y evitar problemas con OOM.
- Además, se verifican casi todas las operaciones aritméticas y conversiones de tipos numéricos (incluso de forma estática).
- En el peor de los casos, la biblioteca puede generar una excepción. En este caso, en la API de C, se detectarán excepciones y la función devolverá un error, pero no fallará.
Y a pesar de todas las garantías de seguridad, ttf-parser también es la implementación más rápida. Por ejemplo, analizar CFF2 es 3.5 veces más rápido que FreeType. Mientras tanto, el análisis de glyf es un 10% más lento que en stb_truetype, pero esto se debe al hecho de que no admite fuentes variables, cuya implementación requiere almacenamiento adicional. información. Más detalles en README.
Fuente: linux.org.ru