¿Qué cambia al pasar de SVG a PDF? viewBox, unidades y lógica tipográfica

El SVG es un formato de gráficos web: flexible, escalable y adaptable a la pantalla. El PDF es un formato de página: fijo, físico y ligado a la impresión. Aunque los dos comparten el mismo modelo de dibujo vectorial, esa diferencia de filosofía produce consecuencias concretas en la conversión. En este artículo explicamos esas diferencias y por qué algunos SVG se convierten a PDF con tamaños inesperados.

Dos concepciones distintas de "página"

En el PDF, la página es física. Cada objeto de página tiene un MediaBox, un rectángulo fijo expresado en puntos. Una página A4 mide 595 × 842 puntos, siempre y en todas partes. El contenido se coloca directamente en ese sistema de coordenadas. No existe el concepto de "ajustar a la pantalla": el visor amplía, pero la página en sí no cambia.

En el SVG, la "página" es relativa. Un SVG no tiene un tamaño natural; el contenido se define en un sistema de coordenadas y ese sistema se puede escalar a cualquier área de visualización. El mismo archivo SVG se puede mostrar con 100 píxeles de ancho en un sitio y con 1000 en otro, y las dos cosas son correctas.

Esa diferencia de filosofía obliga a tomar una decisión en la conversión: al colocar un gráfico flexible en una página fija, ¿qué escala se usa?

viewBox: el sistema de coordenadas del SVG

El atributo viewBox toma cuatro números:

<svg viewBox="0 0 595 842">

Son, en orden: minX, minY, ancho y alto. Significa: "mi contenido está definido en un área de 595 unidades de ancho por 842 de alto que empieza en el punto (0,0)".

Todas las coordenadas de dentro se expresan en ese sistema. Si un rectángulo dice x="100" y="200", es en coordenadas del viewBox.

El viewBox no es una medida física. Solo define el sistema de coordenadas interno. Cuánto espacio ocupará realmente ese sistema lo determinan width y height.

width/height: el tamaño de visualización

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

En este archivo, el contenido está definido en un sistema de coordenadas de 595 × 842 unidades y ese sistema se escala a un área de 210 × 297 mm. Es decir, 1 unidad de usuario equivale a unos 0,353 mm, que es exactamente 1 punto (1/72 de pulgada = 0,3528 mm).

Piensa ahora en el mismo contenido con otro width:

<svg width="105mm" height="148.5mm" viewBox="0 0 595 842">

El contenido es el mismo, pero se muestra a media escala, en tamaño A5.

Ambigüedad de unidades: la fuente de problemas más frecuente

El problema empieza cuando width y height se escriben sin unidad:

<svg width="595" height="842" viewBox="0 0 595 842">

Eso deja sin responder la pregunta "¿595 de qué?". Hay dos interpretaciones distintas y entre ellas hay un 33 % de diferencia:

| Interpretación | 1 unidad | 595 unidades | |---|---|---| | Convención PDF/impresión: puntos | 1/72 de pulgada | 210 mm (ancho de A4) | | Convención web/CSS: píxeles | 1/96 de pulgada | 157 mm |

Los conversores suelen usar la interpretación en puntos y dan un resultado correcto. Pero en los SVG que vienen del entorno web (los que produce una librería de gráficos o los que guarda una herramienta de navegador) puede haber valores generados suponiendo píxeles, y entonces el PDF resultante sale más grande de lo esperado.

Peor todavía si width/height no están:

<svg viewBox="0 0 800 600">

En ese caso el conversor hace una conjetura pura. Unos toman los valores del viewBox como puntos, otros los ajustan a un tamaño de página por defecto y otros suponen píxeles CSS.

La solución es sencilla: antes de convertir el SVG a PDF, abre el archivo en un editor de texto y escribe los valores de width y height con unidad física:

<svg width="210mm" height="297mm" viewBox="0 0 595 842">

Esa única edición elimina por completo la ambigüedad.

preserveAspectRatio: qué pasa cuando las proporciones no coinciden

Si la proporción del viewBox no coincide con la de width/height, lo que ocurre lo determina el atributo preserveAspectRatio. Su valor por defecto es xMidYMid meet: el contenido se ajusta al área manteniendo la proporción y se centra, dejando espacio libre donde sobra.

El valor slice hace lo contrario: el área se rellena por completo y las partes que sobresalen se recortan.

En la conversión a PDF eso se manifiesta como márgenes en blanco inesperados o contenido cortado. Si hay desajuste, igualar las proporciones del viewBox y de width/height es la solución más limpia.

Tipografías: la diferencia filosófica de fondo

Esta es la distinción práctica más importante entre los dos formatos.

El PDF incrusta las tipografías. La razón de ser del formato es que el documento se vea igual en todas partes. La única forma de garantizarlo es meter en el archivo los datos de dibujo de las tipografías usadas. Cuando abres un PDF, la tipografía que ves es la que el propio archivo lleva dentro.

El SVG normalmente no las incrusta. Escribe font-family="Roboto" y espera que esa tipografía esté en el entorno de visualización. En la web eso se resuelve cargando un archivo de tipografía con @font-face de CSS, pero esa información puede estar en el CSS de la página y no en el propio archivo SVG.

Lo que ocurra en la conversión depende de si el conversor puede acceder a esa tipografía:

• Si puede: la tipografía se incrusta en el PDF y el texto sigue siendo texto real. Seleccionable, localizable y accesible.
• Si no puede: se recurre a una tipografía parecida. Los anchos de letra cambian, la alineación se desplaza y las líneas largas pueden desbordarse o acortarse.

Lo traicionero del segundo caso es que el resultado se ve incorrecto pero verosímil. De un vistazo no lo notas; solo al ponerlo junto al original ves que las alineaciones se han desplazado.

Solución definitiva: convertir los textos a curvas (outline/path) en el programa que genera el SVG. Cada letra se convierte en una forma vectorial y la dependencia de la tipografía desaparece. El precio es que el texto deja de poder seleccionarse y buscarse.

Color: no hay salida del RGB

El SVG es RGB por naturaleza. Escribes fill="#3366CC" o fill="rgb(51,102,204)". No existe el concepto de CMYK.

El PDF, en cambio, admite CMYK, tintas planas y perfiles de color ICC, porque está diseñado para la impresión.

En la conversión de SVG a PDF los colores se trasladan como RGB. Eso no es problema para el uso en pantalla, pero es una carencia en un archivo que va a imprenta: la imprenta pide CMYK y, al recibir un archivo RGB, hace la conversión por su cuenta, con un resultado que puede diferir del que tú veías. Los verdes vivos, los naranjas y los negros ricos salen especialmente distintos.

Si el trabajo de impresión es serio, hay que pasarlo a CMYK en un programa de diseño después de la conversión.

Filtros y rasterización

El elemento <filter> del SVG ofrece efectos potentes: desenfoque gaussiano, sombra, matriz de color, iluminación, turbulencia.

El modelo de transparencia y efectos del PDF es distinto y la mayoría de esos filtros no tienen equivalente directo.

El conversor tiene dos opciones:

1. Usar un equivalente aproximado. Es posible para la transparencia alfa simple y algunos modos de fusión.

2. Rasterizar esa zona. El área con filtro se renderiza como imagen y se coloca en el PDF como píxeles.

Lo segundo da el resultado visualmente correcto pero hace perder la nitidez vectorial. Al ampliar el PDF, esa zona se pixela. Al imprimir se ve como un área de baja resolución.

Por eso, en los SVG que van a imprenta es más seguro evitar los filtros e imitar los efectos de sombra y desenfoque con vectores.

Todo lo dinámico se fija

El SVG es una tecnología web y eso tiene consecuencias:

| En el SVG | En el PDF | |---|---| | Animación SMIL | El primer fotograma o el estado inicial | | Animación o transición CSS | Se fija | | Estilos :hover | No se aplican, queda el estado normal | | Contenido generado con JavaScript | Se traslada si el conversor lee el DOM; no, si lee el archivo | | <foreignObject> (HTML incrustado) | Normalmente se pierde | | Archivo CSS externo | Puede no aplicarse |

Las dos últimas filas son importantes: si tu SVG depende de un archivo CSS externo o de JavaScript, el archivo por sí solo está incompleto. Antes de convertir hay que incrustar los estilos dentro del SVG (atributos style en línea o un bloque <style>).

Lo que se gana

En la conversión no solo se pierde; el PDF también aporta cosas:

• Incrustación de tipografías: el archivo pasa a bastarse a sí mismo.
• Varias páginas: se pueden reunir varios SVG en un solo documento.
• Control de impresión: el tamaño de página, la orientación y los márgenes quedan definidos.
• Propiedades de documento: son posibles los metadatos, los marcadores y la firma digital.
• Apertura universal: se comporta como se espera en cualquier dispositivo.

En resumen

El SVG trabaja en un sistema de coordenadas flexible y relativo; el PDF se basa en una lógica de página fija y física. La mayoría de los problemas de la conversión nacen de esa diferencia: cuando no se especifica la unidad de width/height, el tamaño de página queda a merced de una conjetura (la distinción entre puntos y píxeles supone un 33 % de diferencia); como en el SVG las tipografías no van incrustadas, el resultado depende de que el conversor pueda acceder a ellas; los colores no pueden salir del RGB; y los filtros complejos provocan rasterización y hacen perder la nitidez vectorial. Todos esos problemas se pueden resolver de antemano: escribe unidades físicas, convierte los textos a curvas, evita los filtros y, si va a imprenta, planifica la conversión de color como un paso aparte.