Escribir un dibujo
para entender la máquina

Concepto Representación mínima de datos, XML como formato de dibujo

printf '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><circle cx="50" cy="50" r="40" fill="#4fd9e8"/></svg>\n' > mano.svg
wc -c mano.svg

116 mano.svg

mano.svg pesa 116 bytes y es un dibujo completo: un círculo cian de radio 40 dentro de un lienzo de 100 por 100 unidades. Ningún programa de dibujo estuvo involucrado. El navegador lo abre directo — probalo con doble clic o arrastrándolo a una pestaña.

El favicon de esta misma página es el mismo truco: favicon.svg pesa 192 bytes y se referencia así, sin conversión a ningún formato binario:

<link rel="icon" href="favicon.svg" type="image/svg+xml">

Ahora escribilo de nuevo, a mano, en el editor de abajo — es el mismo mano.svg, prellenado. Borrá algo, cambiá el radio, mirá qué pasa. La última línea de este módulo es el widget: escribís texto y aparece un dibujo, en vivo.

El momento Borrá el / antes del > de cierre del circle y mirá la línea de estado: el mismo parser estricto que va a protagonizar el módulo 7 ya está corriendo en este editor, en tiempo real, cada vez que tipeás.

Concepto Sistemas de coordenadas anidados, unidades de usuario

viewBox="0 0 100 100" no es un tamaño en píxeles: es una declaración de unidades de usuario, un sistema de coordenadas propio del dibujo. Sin width ni height, el SVG escala para llenar el contenedor donde lo pongas — por eso todos los dibujos de este sitio están escritos así a propósito: para que se incrusten de forma responsiva, sin media queries por dibujo.

Eso significa que hay al menos dos sistemas de coordenadas superpuestos: el interno, en unidades de usuario (los números que escribís en cx, r, d), y el externo, en píxeles de pantalla. La matriz que traduce uno al otro se llama CTM — current transformation matrix — y se puede leer, no solo intuir.

Ese factor 2 no es un redondeo ni una coincidencia de esta página: es la definición de viewBox funcionando. El navegador compone tu matriz con la suya — la que traduce las 200 unidades del viewBox al ancho real del contenedor — y getCTM() te devuelve el resultado ya multiplicado. Es la demostración más limpia que hay de que "sistema de coordenadas anidado" no es una frase abstracta: es un número que podés leer en la consola.

El momento Nunca hay un solo sistema de coordenadas en un SVG. Hay como mínimo dos, y getCTM() es la ventana a la matriz que los conecta. El módulo 3 va a mostrar que esa misma matriz también puede escribirse a mano, número por número.

Concepto DSL embebido, parsing declarativo, interpretación de una cadena

cat > camino.svg <<'EOF'
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 120">
  <path d="M 20 100 L 60 30 L 100 100 Z" fill="none" stroke="#4fd9e8" stroke-width="3"/>
  <path d="M 120 100 C 140 20, 180 20, 200 100" fill="none" stroke="#f26fc0" stroke-width="3"/>
  <path d="M 220 100 Q 250 10, 280 100" fill="none" stroke="#6fd88a" stroke-width="3"/>
</svg>
EOF

Cada letra de d es un comando de un lenguaje chico: M mueve el lápiz sin dibujar (moveto), L dibuja una recta (lineto), C dibuja una curva de Bézier cúbica con dos puntos de control, Q una cuadrática con uno solo, y Z cierra la figura volviendo al punto de partida. Medido con getTotalLength() sobre cada uno de los tres path de arriba:

Ese número no está adivinado ni interpolado a ojo: getTotalLength() hace que el navegador mida, en unidades de usuario, la longitud real de una curva que parseó de una cadena de caracteres. La cadena "M 120 100 C 140 20, 180 20, 200 100" es un programa chico, con su propia sintaxis y su propio conjunto de comandos, y el navegador tiene un intérprete de ese programa integrado en el motor de renderizado. Un DSL completo, viviendo adentro de un atributo.

El momento No hay una "forma curva" guardada en algún lado: hay una cadena de texto que un intérprete lee, comando por comando, y convierte en geometría. El atributo d es la prueba más chica y más legible que existe de qué es un lenguaje de dominio específico con su propio parser.

Concepto Álgebra lineal como sintaxis de atributo, composición de matrices

La sintaxis amigable de transform —rotate, translate, scale— no es una capa por encima de algo más simple: es azúcar sintáctico sobre una matriz afín de 2×3, y el navegador la compila a esa matriz antes de dibujar nada. rotate(30) translate(40 0) compone, en unidades de usuario, exactamente a:

matrix(0.8660254 0.5 -0.5 0.8660254 34.641016 20)

La cuenta a mano: rotate(30) es la matriz [cos30, sin30, -sin30, cos30, 0, 0] = [0,866, 0,5, -0,5, 0,866, 0, 0]. Componer translate(40 0) encima multiplica esa traslación por la parte rotada de la matriz: e = 0,866 × 40 = 34,641 y f = 0,5 × 40 = 20. Nada de esto es magia del navegador — es la multiplicación de matrices de toda la vida, aplicada dos veces y sumada.

Volvé a mirar el dibujo incrustado en el módulo 1: el grupo compuesto usa la sintaxis amigable, el grupo amano usa los seis números crudos de arriba, y en pantalla se superponen sin que se vea un solo píxel de diferencia. Pero medilos con getCTM() y no son idénticos. Estos son los cuatro componentes de escala y rotación, medidos:

compuesto  1.7320508075688774   0.9999999999999999  -0.9999999999999999   1.7320508075688774
amano      1.732050895690918    1                   -1                    1.732050895690918
diferencia máxima: 0.000003524881620364795

Tres cosas para mirar de esa salida, y ninguna es un error del navegador:

• El 1 que no es 1. rotate(30) debería dar sin 30 = 0,5 exacto. En aritmética de punto flotante sin(30°) vale 0,49999999999999994, y por eso el componente aparece como 0,9999999999999999 después de escalar. No es el SVG: probá Math.sin(30 * Math.PI / 180) en cualquier consola y en Python te da lo mismo.
• Se separan en el sexto decimal. La diferencia máxima es 3,52 × 10⁻⁶ de unidad de usuario. Componer dos matrices y multiplicarlas en el momento no acumula el mismo redondeo que escribir el producto ya hecho. Son dos caminos aritméticos al mismo lugar.
• Escribir más decimales no cambia nada. Verificado: matrix(0.8660254 ...) y matrix(0.8660254037844387 ...) devuelven resultados byte a byte iguales. Los números de los atributos se guardan con precisión reducida, así que a partir del séptimo dígito estás escribiendo decoración.

Y aun así: 3,5 millonésimas de unidad de usuario, en un dibujo de 200 unidades de lado, es una fracción invisible de un píxel. Se superponen perfectamente a la vista porque el error es del orden del redondeo, no de la geometría. La conclusión sigue en pie y ahora está medida en vez de afirmada.

Esta misma matriz de 2×3 ya la usaste en otra forma, en el taller anterior de esta serie. En pixel-playground escribiste un kernel de convolución de 3×3: una matriz chica que se desliza sobre una imagen. Son la misma clase de objeto matemático haciendo trabajos distintos. El kernel de convolución combina los valores de los píxeles vecinos — multiplica y suma intensidades. La matriz afín de transform reubica coordenadas — multiplica y suma posiciones. Una opera sobre qué tan brillante es un punto; la otra, sobre dónde está. Multiplicar-y-sumar es el núcleo de las dos, y es el núcleo de casi toda la computación gráfica.

El momento rotate(), translate() y scale() no son primitivas independientes: son nombres legibles para casos particulares de una única matriz de 2×3. Escribirla a mano, número por número, y verla caer encima de la versión legible con un error de una millonésima es la prueba de que no hay dos sistemas — hay uno solo, con dos formas de nombrarlo y dos caminos de redondeo para llegar.

Concepto Generación procedural, programa como dibujo

for i in $(seq 1 60); do
  printf '  <circle cx="100" cy="100" r="%d" fill="none" stroke="#4fd9e8" stroke-opacity="0.35" transform="rotate(%d 100 100) translate(%d 0)"/>\n' \
    "$((100 - i))" "$((i * 6))" "$((i / 2))"
done >> espiral.svg

Ningún programa de dibujo estuvo involucrado en ningún paso. El bucle no generó una imagen que después se convirtió a SVG: generó directamente el texto del SVG, línea por línea, con la misma herramienta con la que un script genera cualquier otro archivo de texto. path del módulo 2 y transform del módulo 3 son lo único que hizo falta aprender para que esto sea posible.

El momento Un dibujo generativo no necesita un lenguaje de shaders ni un motor de partículas. Necesita una forma, un atributo que varíe con el índice del bucle, y printf. La distancia entre "escribir un archivo de texto" y "escribir un programa que dibuja" es más chica de lo que parece.

Concepto Representación por regla vs. representación por muestra, independencia de resolución

El mismo dibujo de 60 círculos del módulo 4, exportado a raster a tres tamaños distintos, contra el peso del propio SVG:

El SVG pesa 8.194 bytes en las tres filas. No cambia. El PNG crece aproximadamente con el área — de 200×200 a 2000×2000 el área se multiplica por 100, y el PNG por casi 28. La razón de la diferencia no es un detalle de compresión: es que el SVG no guarda una imagen, guarda una receta — 60 elementos circle con sus atributos — y esa receta se ejecuta en el momento de dibujar, a cualquier resolución que pida el dispositivo. El PNG, en cambio, guarda el resultado de ejecutar esa receta una vez, congelado en una grilla de píxeles de un tamaño fijo.

Mostrados al mismo tamaño en CSS, escalá la página del navegador hacia arriba y mirá los dos: el SVG se mantiene nítido, el PNG empieza a mostrar sus píxeles.

Esto es la misma familia de idea que pixel-playground, módulo 5, donde cuantizar una imagen a 2 colores no le sacaba un solo byte al PPM crudo — el formato reserva espacio fijo por píxel sin importar cuánta información real hay adentro. Ahí la lección era que menos información no es menos bytes. Acá es la otra cara de la misma moneda: lo que un archivo guarda y lo que representa son preguntas distintas, y la independencia de resolución del SVG es la versión más extrema y más medible de esa distinción que vas a ver en todo el taller.

El momento Guardar una receta en vez de un resultado no es una optimización de espacio que a veces funciona: es una propiedad estructural que se sostiene siempre, y la tabla de arriba la vuelve un número concreto en vez de una promesa de marketing sobre "gráficos vectoriales".

Concepto Cierre y evaluación

Cada persona guarda el dibujo que más le gustó de todo el taller. No hace falta convertirlo a nada: ya es el archivo final, el mismo que se puede abrir, leer y editar con un editor de texto común.

Y antes de mostrarlo, dice una sola frase: qué parte de su dibujo es receta y no resultado — un transform, un bucle, un path que reutilizó. Esa frase es toda la evaluación del taller. Si puede decirla, entendió que el dibujo es texto y que eso no es un detalle técnico sino la razón por la que todo lo anterior funcionó. Si no puede, el dibujo queda igual de lindo — pero volvemos 10 minutos al módulo 3.

El momento El que aparece cuando alguien mira el archivo de otro y dice, sin que se lo pidan, "esto lo podés versionar". Ahí dejaron de ver una imagen y empezaron a ver un documento.