Commits
Auto Magazine: el MVP funciona de principio a fin con el número real
El material real destapa los errores, la exportación a imprenta llega con CMYK y preflight, y la fase principal se cierra con el informe todo en verde.
El proyecto ha llegado donde quería llegar desde el primer día: el informe de imprenta, todo en verde, con el número real del usuario dentro. El criterio de aceptación del mapa wayfinder —un número maquetado y exportado de principio a fin, pasando el preflight y sin edición manual intermedia— se cumplió y cerró la fase principal con treinta y siete pruebas en verde.
El material real destapa lo que no ven las pruebas
La mañana fue intensa. Maquetar en producción no funcionaba y los registros del contenedor mostraron un AssertionError dentro de WeasyPrint: la capitular, una letra inicial con float en ::first-letter, funciona cuando el artículo comienza en una página nueva, pero falla cuando el flujo continuo divide el primer párrafo entre dos páginas. Retiramos el float y la letra queda grande y del color de la marca sin flotar; la capitular realmente flotante queda anotada como un deseo de diseño que hoy no es fiable en WeasyPrint.
A continuación, las fotos de los artículos reales no aparecían: estaban ancladas como imágenes flotantes de Word (wp:anchor), que la biblioteca python-docx no expone por defecto. La extracción ahora las lee directamente del XML del documento, en orden de aparición, junto con las imágenes insertadas en el texto. Y aún quedaba una sutileza: la foto destacada que procedía de la subcarpeta desaparecía del PDF porque dos listas se repartían la responsabilidad. La galería la excluía por ser la destacada, y el espacio de destacado solo sabía dibujar imágenes incrustadas en el documento. Ahora la solución es única: la destacada se dibuja venga de donde venga (identificada por su huella digital o SHA1) y todo el resto cae en la galería, con la garantía de que ninguna imagen se queda sin sitio.
Exportar a imprenta, con franqueza
La sexta fase trajo el botón «Exportar a imprenta»: conversión real a CMYK (el modelo de color que usan las máquinas de impresión con cian, magenta, amarillo y negro) mediante Ghostscript, metadatos con pikepdf y un preflight automático. El preflight es un control de calidad que verifica que el documento cumple todos los requisitos técnicos antes de imprimir. El informe se muestra en verde o rojo en el panel y comprueba que las páginas sean múltiplos de 4, que el TrimBox (el tamaño final de corte) se aplique a todas las páginas, que el sangrado sea de al menos 3 milímetros y que se verifique la resolución efectiva de las imágenes.
Tomamos dos decisiones de franqueza: sin Ghostscript en el entorno, el proceso continúa, pero la conversión a CMYK queda en rojo —el PDF nunca se considera válido a medias— y, cuando no hay binario, las comprobaciones declaran «no disponible» en lugar de fingir una medición. Y aún resultó positiva otra: el informe marcaba en rojo el color CMYK sin más detalle, y la causa era un -d donde debía ir un -s: ColorConversionStrategy es un parámetro de cadena y se estaba pasando como flag. Con la opción correctamente pasada, el PDF final lleva imágenes en DeviceCMYK de verdad, verificado con pikepdf.
El MVP, de principio a fin
Con todo esto, la fase principal queda cerrada por completo: hotfolder (una carpeta vigilada que procesa los archivos automáticamente cuando se deposita material en ella), extracción por capas con IA, maquetación con plantillas planas y tema, paginación con flujo continuo y páginas múltiplos de 4, y exportación a imprenta con CMYK y preflight. Ninguno de estos errores habría aparecido con material sintético: probar con el número real del usuario fue lo que los destapó a todos. Abre la fase de revisión y pulido, con las fricciones ya señaladas en el mapa y las mejoras que el usuario quiera solicitar.