Los 4 huecos que la impresión de código abierto está cerrando

Lo que la impresión open source está cerrando esta vez es el tramo medio, el que más fácil se rompe entre el ordenador y el equipo. OpenPublishing publicó el 2026-07-26 sus 11 proyectos de Google Summer of Code 2026, centrados en CUPS 3.x, PDFio, CI, fuzz testing, simulación de impresoras y escáneres, y local ML driver lookup

OpenPrinting (el grupo de proyectos de impresión open source que participa en GSoC como sub-organización de la Linux Foundation y mantiene las herramientas y datos de impresión en Linux/Unix), yo traduzco este empujón a una frase de taller: si el ordenador encuentra o no a la máquina, si el PDF se desmonta bien en datos imprimibles, y si después de una actualización algo se rompe del lado del cliente

Google Summer of Code (el programa de Google para que personas contribuyentes desarrollen proyectos de código abierto guiadas por mentores) suele sonar muy de ingeniería, pero quien compra impresión tiene que mirar dónde está el riesgo. Las averías de impresión rara vez viven en un solo punto: archivo, driver, sistema operativo y firmware del equipo se van pasando la pelota. Justo en esos límites de responsabilidad es donde la impresión open source está apretando

CUPS 3.x le importa a quien compra porque empuja la gestión de impresión hacia IPP print destinations y Printer Applications, y la lógica clásica de instalación de drivers PPD se va quedando atrás

CUPS (Common Unix Printing System, el sistema de impresión típico en Unix/Linux, que recibe, pone en cola, aplica opciones y envía los trabajos) es la centralita de muchos flujos de impresión en Linux. IPP (Internet Printing Protocol, el estándar de comunicación para impresión en red, que permite al ordenador y al equipo hablar el mismo idioma para encontrarse, consultar capacidades y mandar trabajos) es el idioma común que usan los equipos para entenderse

OpenPrinting comenta que KDE Print Manager está atendiendo a la vez CUPS 2.x y CUPS 3.x, y ha separado las pruebas para poder elegir el camino según la versión. Otro proyecto de CI mete libppd, libpappl-retrofit, libcupsfilters, cups-filters y cups-snap en un banco de pruebas automático, cubriendo CUPS 2.4.x, 2.5.x, 3.x/libcups3 y 4 arquitecturas

Cuando compres, no preguntes solo «¿se puede imprimir?». Pregunta si el equipo soporta IPP driverless, si la máquina vieja necesita una Printer Application, si el panel de administración deja ver el estado y quién se encarga de validarlo después de una actualización del sistema operativo. Con esas cuatro preguntas contestadas, la oferta se queda mucho más callada

El PDF renderer cierra la conversión del PDF al raster que el equipo sabe masticar; el fuzz testing cierra pasar el programa por una ronda de archivos rotos, raros y formatos en el límite antes de que lleguen de verdad

PDFio (la librería de PDF que mantiene Michael Sweet, que permite a otros programas leer y escribir la estructura de un PDF) se está extendiendo hacia un PDF renderer con licencia permisiva. Para alguien de a pie es bien simple: que un PDF se vea bien en pantalla no significa que la impresora entienda directamente las tipografías, las imágenes, los márgenes de página y la resolución que lleva dentro; el renderer tiene que desarmar el PDF en píxeles y pasárselos al equipo

El PDFio renderer del material ya hace target DPI scaling, page boundary constraints y /XObject resource mapping, y usa FreeType para leer las tipografías TrueType en /FontFile2. Cuando una fuente se rompe o falta, cae a DejaVuSans.ttf. Quien sabe del tema frunce el ceño al leer esto, porque si el interletraje se mueve, lo que ve el cliente no es deuda técnica, es un acabado torcido

El fuzz testing (técnica que bombardea un programa con entradas anómalas para encontrar cuelgues y agujeros de seguridad) también está tapando riesgo. El proyecto cups-filters fuzzing de OpenPrinting usa AFL++, Honggfuzz y OSS-Fuzz-Gen, y convierte 1.079 raw crashes en 22 unique clusters tratables. No es romántico, pero se parece bastante a lo que vive cada día un taller cuando le llegan PDFs raros

Una parte del flujo de impresión se puede probar sin tener el equipo físico. El proyecto go-mfp de OpenPrinting está enganchando impresoras virtuales, colas CUPS y comparación de imágenes en un flujo que corre solo

CI (Continuous Integration, el proceso que compila y prueba automáticamente cada vez que cambia el código) para un taller de impresión significa algo muy llano: que el sistema se haga una pasada antes de actualizar, y no esperar al trabajo urgente del cliente para descubrir la cola caída. El full print system testing pipeline de OpenPrinting carga un virtual printer model, crea la cola CUPS, enumera los print modes, manda print jobs, captura la salida y compara con métricas de imagen tipo SSIM y PSNR

go-mfp (el toolkit en Go de OpenPrinting para simular y probar equipos multifunción) corrigió en la fase 1 tres bugs de IPP attribute-decoding; en la fase 2 levanta un IPP server sobre TCP con CPython embebido, registra la cola con lpadmin y manda un PNG de prueba con lp. Es bien simple: primero te estrellas en software, y cuando el equipo real sale a producción no hay que estar llamando al técnico de madrugada

El lado del escaneo también se está cubriendo. IPP-Scan es el estándar de driverless scanning over IPP definido por la Printer Working Group en 5100.17, y go-mfp está metiendo cliente y servidor. Para empresas con flujo de escaneo, impresión y archivo, esto significa que «se puede escanear» también va a entrar en el mismo idioma de validación

Lo que toca hacer ahora a un taller pequeño o mediano es convertir la jerga de la impresión open source en una lista de validación: primero compatibilidad, después pruebas, y al final reparto de responsabilidades

Yo lo pasaría por las «tres puertas de MINDS (MS, impresión comercial a medida de gama media-alta) para mandar a imprenta» cuando entre equipo nuevo o flujo nuevo:

・① Puerta del archivo: tamaño de página del PDF, sangría, incrustación de tipografías, resolución y modo de color, todo validado de entrada

・② Puerta del equipo: confirmar que soporta IPP, si tira de Printer Application, y si el panel de administración deja ver el estado

・③ Puerta de pruebas: quedarse con un archivo de prueba estándar y anotar versión de CUPS, driver, nombre de cola y mensajes de error

Para un catálogo de alta exigencia, papel especial o propuesta de marca, yo mandaría primero el archivo a MINDS para dejar claro quién responde de qué; si son tarjetas de visita, pegatinas o un folleto corto, mejor pasar por Mai Yin Shua y dejar la ficha técnica bien cuadrada desde el principio

Para el diseñador, lo que la impresión open source está cerrando es la previsibilidad antes de mandar a imprenta. Para el taller, es un idioma común entre IT y línea de producción. Para quien compra, es la capacidad de hacer preguntas: no te quedes solo mirando la hoja de especificaciones, mira quién puede demostrar que el equipo sigue sacando papel estable después de actualizar

・Esta tanda de impresión open source cierra la responsabilidad del tramo medio: el equipo tiene que encontrarse, el archivo tiene que imprimirse y el error tiene que poderse seguir

・La pregunta de compra sobre CUPS 3.x es bien concreta: el equipo nuevo tiene que saber IPP driverless, y el viejo tiene que tener claro de qué Printer Application tira

・El PDF renderer y el fuzz testing destapan los archivos malos antes; eso ahorra más que devolver el trabajo cuando ya está en máquina

・Un taller pequeño o mediano primero se monta un archivo de prueba y un registro de versiones; entonces IT y línea de producción hablan el mismo idioma

En el lado de producción hay que poner CUPS, IPP y Printer Applications dentro de la lista de validación del equipo; en el lado de diseño, la preflight del PDF tiene que ser un paso fijo antes de mandar a imprenta; al meter IA, no vale solo con mirar el borrador generado, también tiene que revisar sangría, tipografías, resolución y modo de color; si un equipo SaaS quiere servir al flujo de impresión, lo primero es dejar como campos consultables el estado de la cola, el registro de errores, la versión del archivo y las capacidades del equipo, que eso da más juego que subir otra página de subida bonita

・OpenPrinting 2026 GSoC, estado del desarrollo