Hace casi diez años publiqué un pequeño proyecto que me hacía bastante ilusión: una fuente Unicode inspirada en la tipografía del ZX Spectrum.
La idea era sencilla. Recrear la fuente original, extenderla con caracteres Unicode que nunca existieron en el Spectrum y generar automáticamente la tipografía a partir de una colección de SVG mediante scripts de FontForge.
Durante años el proyecto ha permanecido prácticamente congelado. Funcionaba, seguía siendo útil y nunca encontré una razón suficientemente buena para retomarlo… Hasta ahora.
Empezar por una simple actualización…
Mi intención inicial era bastante modesta. Por una idea relacionada me di cuenta de que el repositorio tenía ya 10 años. Por simple curiosidad quería revisar los scripts, comprobar qué herramientas existen hoy en el ecosistema open source y modernizar el proceso de generación de la fuente.
En estos diez años el panorama ha cambiado muchísimo. Hoy existen formatos como UFO, herramientas como fontmake y pipelines reproducibles integrados con GitHub Actions que hacen que construir una tipografía sea mucho más parecido a compilar un proyecto software que a editar un archivo binario.
Pensaba que el cambio consistiría únicamente en sustituir unas herramientas por otras. Pero la investigación fue derivando hacia una pregunta mucho más interesante.
¿Cuál es realmente el código fuente de una tipografía?
Hasta ahora siempre había considerado que el origen del proyecto eran los SVG de cada glifo. Sin embargo, cuanto más analizaba el diseño original, más evidente resultaba que los SVG no contienen realmente el conocimiento del proyecto.
Lo que contienen es el resultado final.
Las decisiones importantes están en otro sitio.
Algunas preguntas que hace 10 años respondí con soluciones expresadas en los propios dibujos en los SVGs, en realidad encerraban cuestiones muy interesantes:
- ¿Por qué las mayúsculas acentuadas son ligeramente más bajas?
- ¿Cómo se separan ópticamente los diacríticos?
- ¿Cuándo una esquina debe redondearse?
- ¿Qué formas son realmente reutilizables?
Todas las respuestas existen… pero únicamente en mi cabeza.
Y eso significa que el verdadero diseño nunca ha estado descrito explícitamente.
De dibujos a reglas
Ahí apareció una idea que me fascinó. ¿Y si en lugar de almacenar dibujos almacenáramos reglas?
No describir un glifo como un conjunto de curvas o incluso de píxeles, sino como una descripción declarativa capaz de generar esos dibujos.
Eso abriría la puerta a procesos interesantes:
- Generar automáticamente variantes de un carácter;
- Modificar el radio de las esquinas para toda la fuente;
- Separar ligeramente los acentos para mejorar la legibilidad;
- Crear distintos estilos (clásico, suavizado, accesible…) a partir de la misma definición.
En lugar de mantener cientos de SVG independientes, se podría construir un pequeño motor capaz de reconstruir toda la tipografía.
Pero sin perder la esencia
Y hay un detalle que considero importante. No me interesa un lenguaje descriptivo extremadamente potente si deja de ser legible para las personas.
Una de las cosas que más me gustan de una fuente inspirada en un ordenador de 8 bits es que el diseño es lo suficientemente simple como para caber en una cuadrícula de 8×8. Es algo simple, poca información, me gustaría representarlo de la misma forma, algo que puedas reconocer inmediatamente.
Me gustaría conservar esa propiedad.
Quizá utilizando una representación visual basada en una cuadrícula, enriquecida con algunos símbolos Unicode capaces de describir conexiones, diagonales o esquinas, pero que siga siendo reconocible de un simple vistazo.
Si dentro de otros diez años abro uno de esos ficheros en GitHub, quiero reconocer inmediatamente la letra que estoy viendo, y ser capaz de entender las sutilezas en un vistazo más profundo.
Quizá ya no sea una fuente
Lo curioso es que la idea ha terminado creciendo mucho más de lo esperado. Ya no pienso en una actualización de la ZX Spectrum Unicode Font. Empiezo a pensar en un pequeño lenguaje declarativo para describir tipografías basadas en rejillas discretas.
Puede que nunca llegue a convertirse en un proyecto completo.
Estoy seguro de que durante el desarrollo descubra problemas que hoy ni siquiera imagino.
Pero pocas veces una simple intención de “actualizar unos scripts antiguos” termina convirtiéndose en una oportunidad para replantear completamente un proyecto.
Y eso, por sí solo, ya hace que merezca la pena intentarlo.
