Desde la versión 2.58.0, librsvg ya no usará gdk-pixbuf
para decodificar las imágenes de pixeles que se referencian desde
documentos SVG. Por ejemplo, en los elementos <image> como éste:
<image href="foo.jpg" width="100" height="100"/>
Acabo de meter un merge request para hacer que librsvg use el huacal
image-rs para decodificar imágenes de pixeles. Esto forma
parte de dos cambios relacionados:
-
Cargar sub-documentos SVG sin usar gdk-pixbuf. Por razones históricas, el código original en C de librsvg ni siquiera se molestaba en detectar si algo como
<image href="foo.svg"/>hacía referencia a otro documento SVG; sencillamente le pedía a gdk-pixbuf que cargara esa imagen como cualquier otra. Esto funcionaba más o menos bien para SVG1.1, pero en SVG2 sí tenemos que mirar los atributos del<image>y del documento hijo SVG, y es más sencillo que librsvg se llame a sí misma para hacer todo eso. -
No usar gdk-pixbuf para decodificar imágenes de pixeles. Ahora que Loupe usa los mismos huacales en Rust para decodificar imágenes, creo que podemos empezar a mover el resto e la plataforma para que no use codecs sin seguridad de memoria.
Librsvg todavía compila e instala el decodificador de SVG para
gdk-pixbuf, para que otras aplicaciones puedan renderizar documentos
SVG como si fueran cualquier imagen. Las APIs en C que crean objetos
GdkPixbuf siguen funcionando como siempre.
Se buscan probadores
Como te podrás imaginar, esta es la clase de cambio que me da un poco de ansiedad. Digan lo que digan sobre el código sin seguridad de memoria como libpng y libjpeg-turbo, ese código está muy bien probado y se le hace fuzzing todo el tiempo. Los huacales de Rust para decodificar imágenes todavía no están tan bien desarrollados, y hay mucho trabajo interesante por hacer en términos de desempeño y soporte para las variantes exóticas de esos formatos gráficos. Sin embargo, creo que esta es una buena oportunidad para encontrar exactamente qué es lo que les falta.
Por favor prueba la rama main de librsvg, especialmente si usas
documentos que tienen elementos <image>. Los cambios descritos aquí
son fáciles de revertir, o de hacer opcionales, en caso de que causen
muchos problemas.
