Convertir SVG a GIF

Esto conviene aclararlo antes de convertir nada, y casi ningún sitio que ofrece esta conversión lo menciona. El GIF sí tiene transparencia, pero solo de una forma: una sola entrada de su tabla de color puede marcarse como invisible. El codificador usado aquí no marca ninguna. Construye una paleta, la escribe como una lista de valores rojo-verde-azul, y para cuando el archivo está montado ya no queda ningún sitio donde guardar la información de alfa.

Un render hecho a partir de un SVG tiene píxeles transparentes donde no se dibujó nada, así que cada uno de ellos tiene que volverse opaco antes de construir la paleta. Se rellenan con el color de fondo elegido en esta página, que empieza en blanco. Un logotipo dibujado sobre nada llega entonces como un logotipo sobre una tarjeta blanca: invisible sobre una página blanca y perfectamente visible sobre una oscura, que es justo lo que conviene comprobar antes de enviarlo a algún sitio.

El selector de color de fondo de esta página decide en qué se convierten las zonas vacías, y se lee antes de que ocurra cualquier otra cosa: el relleno se pinta primero sobre el lienzo y el dibujo renderizado se compone encima en una sola pasada. Ese orden es lo que deja los bordes limpios. Rellenar después, o escalar un render transparente y rellenarlo luego, deja un borde de píxeles semitransparentes en cada curva que el relleno oscurece.

Ajusta el valor a lo que vaya a rodear al GIF. Si el destino es una página blanca, déjalo tal cual. Si es un panel de color y conoces el valor hexadecimal, escríbelo y la unión desaparece. Si el destino puede cambiar —una plantilla que este año es blanca y el que viene oscura—, mejor mete un rectángulo que cubra todo el viewBox dentro del propio dibujo, para que el archivo lleve su propio fondo y no dependa de un ajuste puesto una sola vez.

Un SVG no tiene tamaño propio, así que la conversión elige uno: 1.024 píxeles de ancho por defecto, con la altura siguiendo las proporciones del dibujo. Ese valor por defecto va bien con PNG o WebP, donde una imagen plana grande cuesta poco. Le va mal a un GIF, porque los sitios que aún piden uno —firmas de correo, avatares, iconos de foro— trabajan casi siempre entre 100 y 300 píxeles.

Usa el ajuste de escala. A 0,2 el mismo dibujo renderiza a 205 píxeles de ancho, más cerca de lo que muestran esos destinos, y el archivo se reduce más o menos con el área. Enviar un GIF de 1.024 píxeles donde se pedían 150 significa que el software del receptor lo va a reducir, casi siempre mal y sin preguntar.

La reducción es menos brutal de lo que sugiere el número 256, al menos en el tipo de dibujo que suele llegar como SVG. Los rellenos planos usan un color cada uno, los trazos otro más, y el suavizado de bordes añade una gama de tonos intermedios a lo largo de cada contorno —que en un dibujo de dos colores son unas pocas docenas de valores en total.

En un archivo de prueba, el cuantizador produjo una paleta lo bastante pequeña como para escribir una tabla de dieciséis entradas, la menor potencia de dos que la contenía, y el GIF completo de 1.024 por 1.024 pesó 7.844 bytes partiendo de un SVG de 140 bytes. El arte plano comprime muy bien en este formato: el GIF guarda tramos de índices repetidos, y un dibujo son sobre todo tramos.

El caso son los degradados. Un relleno lineal o radial sobre una zona amplia genera cientos de valores distintos, y la paleta no puede contenerlos, así que el cuantizador elige representantes y el resultado escalona en vez de fundirse. En un render de 1.024 píxeles esos escalones se ven con claridad.

Las sombras difuminadas, los bordes borrosos y las superposiciones semitransparentes hacen lo mismo, porque cada una produce una gama de valores mezclados. Si el dibujo tiene algo de esto y el destino no puede convencerse de aceptar otra cosa, renderiza más pequeño: menos píxeles significan menos mezclas distintas y menos bandas visibles.

El SVG puede animarse. Tiene elementos SMIL, responde a animación CSS y un archivo puede llevar script. El GIF también puede animarse, lo que tienta a pensar que ambos conectan. No es así: el motor de render produce un único fotograma fijo en el estado inicial del dibujo, y el codificador escribe exactamente ese fotograma en el archivo.

Así que un logotipo animado sale como su primera pose, y ningún ajuste lo cambia. Producir un GIF en movimiento a partir de un SVG en movimiento es un trabajo distinto por completo: exige reproducir la animación y capturarla fotograma a fotograma, que no es lo que hace un renderizador de imagen fija.

El GIF lleva siendo legible por todo desde 1987, y esa es la única propiedad que le importa a quien escribió el requisito. Clientes de correo, motores de foro, portales de intranet y software corporativo anterior a mediados de los 2000 lo leen todos, y quien fijó el formato quería una respuesta que no fallara en ninguno.

Lee el resto de esa especificación mientras estás ahí. Un requisito lo bastante antiguo como para pedir GIF suele fijar también un tamaño máximo en píxeles y un peso máximo en bytes, y el formato rara vez era la única condición. Acertar con todas a la primera es más rápido que tres intentos rechazados.

Merece la pena probarlo antes de aceptar el compromiso. Muchos sistemas que piden GIF en su texto de ayuda aceptan PNG en su código de validación, porque el texto se escribió antes que el código y el código admite lo que lea la biblioteca subyacente. Si funciona, la transparencia se conserva exacta y la reducción de color nunca ocurre.

Donde el GIF sea realmente obligatorio, acéptalo y elige el color de relleno con intención, en vez de dejar el valor por defecto sin mirarlo. El resultado es entonces una imagen de fondo plano que se decidió, no una que simplemente ocurrió, y se verá igual para todo el que la reciba, que es lo que buscaba el requisito en primer lugar.

Suelta la carpeta. Cada SVG se renderiza a la misma escala y se codifica por separado, y todo vuelve como un ZIP. La paleta se construye por imagen y no para el conjunto entero, así que un mismo color de marca puede caer en un índice ligeramente distinto en dos archivos —invisible en el uso normal, y una razón para no esperar que los archivos sean comparables byte a byte.

Cada archivo conserva también sus propios ajustes, así que el color de fondo se elige por fila y no una sola vez para todo el lote. Para un conjunto que va a una misma plantilla, eso significa fijar el mismo valor en cada uno antes de empezar, en vez de descubrirlo firma a firma; la ventaja es que una carpeta con material para dos fondos distintos no obliga a dividirla en dos tandas.

resvg dibuja el SVG y un codificador pequeño construye el GIF, ambos como WebAssembly funcionando en esta pestaña del navegador. El archivo no se sube a ningún sitio, así que no hay copia guardada en un servidor ni cuenta que crear para usar esto.

Se puede soltar una carpeta entera, hasta cien archivos por tanda y hasta cien megabytes cada uno, sin que eso consuma ninguna capacidad nuestra: el límite práctico pasa a ser la memoria del propio dispositivo, no una cola de espera.

Un GIF técnicamente correcto puede seguir sin encajar en un formulario concreto: algunos sistemas antiguos comprueban el tamaño en bytes contra un límite estricto, otros el ancho o el alto en píxeles, y un rechazo silencioso en la subida es más habitual de lo que debería. Prueba el primer archivo en el sitio real antes de convertir el resto del lote.

Si el formulario indica un peso máximo, ese número —no el que parezca razonable a ojo— es el que debe guiar el ajuste de escala: baja la escala hasta que el archivo de prueba quede por debajo del límite, y usa ese mismo valor para toda la tanda.