Commits
Multi-edición lista: tickets cerrados, tres errores de usuario y una decisión de imprenta
Sesión matutina de tickets (03-06) con una prueba de extremo a extremo en verde y tres informes de usuario que revelaron errores de invisibilidad, el colofón sin altura y una decisión: los PDF del cliente se pintan encima de la plantilla, nunca la reemplazan.
Sábado por la mañana y todo el día dedicados a cerrar la funcionalidad de multi-edición. La sesión venía de la noche del 26 y el plan estaba claro: terminar los tickets pendientes y dejarlo todo listo para validar con material real. Al final no se trata solo de cerrar tickets: el día derivó hacia tres informes de usuario que revelaron problemas más sutiles que los del código nuevo.
La mañana fue rápida. El ticket 03 quedó resuelto con un único mecanismo de «campos fijos + personalizados» compartido por la Identidad de la revista y la ficha de edición: el renderizado deja de leer tema.yaml y numero.yaml, y el contexto de plantillas ahora es revista.* y numero.*, con la plantilla decidiendo qué pintar, tal como habíamos acordado. El ticket 04 trajo la mayor novedad del renderizado: cada lado de la revista acepta una imagen de fondo o un PDF cerrado que reemplaza la página generada. El punto de riesgo técnico —pintar el fondo con WeasyPrint por debajo del contenido— funcionó a la primera, verificado con un PDF real. El ticket 05 convirtió la papelera en una sección de Limpieza con manifiestos: cada eliminación guarda origen, fecha y contenido, y se restaura con un clic.
El resultado más satisfactorio del día fue el ticket 06, la prueba de extremo a extremo de toda la funcionalidad contra una instancia limpia. Se creó la edición n87 con el ISSN como campo personalizado, pintado en la portada, fondo PNG y un anuncio de cierre con sangrado; los dos artículos se cargaron, extrajeron, reordenaron y maquetaron; la exportación dio las ocho comprobaciones en verde y el «Listo para imprenta». Por el camino, el trabajo dejó dos lecciones honestas: la primera exportación salió en rojo porque mi material de prueba no estaba a la altura —foto a 181 ppp, anuncio sin sangrado— y la comprobación previa hacía exactamente su trabajo. Además, qpdf no estaba instalado en el portátil y su aviso hundía el veredicto global; se instaló con Homebrew, igual que Ghostscript.
Al mediodía llegaron los tres informes de usuario, y con ellos la lección más importante del día. El primero: la imagen de portada no se veía. Eran dos fallos superpuestos —WeasyPrint guarda las imágenes en la caché por URL y el fondo siempre se llamaba <lado>.png, de modo que el segundo fondo subido nunca llegaba al PDF— y el definitivo: el fondo iba como <img> con z-index -1, que pinta DETRÁS del fondo del contenedor, y el color oscuro de la portada lo tapaba. La imagen estaba en el PDF, pero era invisible. El segundo informe: el colofón salía arriba y recortado. El anclaje absoluto al pie se resolvía contra la caja del artículo, y el artículo del colofón no tenía altura —bottom: 3mm sobre una caja de altura cero deja el texto colgando arriba—. Solución: height: 255mm, el área útil del A4 con los márgenes de la plantilla.
La lección general es de verificación: mis comprobaciones del ticket 04 contaban XObjects de imagen en la página 1 —la imagen REFERENCIADA estaba allí, la VISIBLE no—. Ahora las pruebas rasterizan con pdftoppm y cuentan píxeles del color esperado: realmente visible o nada. Tres capas para no volver a confundir «está en el flujo» con «se ve»: extracción, píxeles y ojos.
La tercera comunicación acabó en una decisión de arquitectura. El usuario detectó con una captura que la contraportada en PDF del cliente se veía más grande que el resto: su MediaBox viajaba entero al documento final y la página quedaba con otro tamaño físico, un riesgo real de imprenta. Decisión, por propuesta suya: en lugar de reemplazar la página, el PDF del cliente se pinta encima de la página de plantilla con add_overlay de pikepdf, escalado como portada y tomando el TrimBox del cliente como origen si lo tiene. Resultado: todas las páginas comparten el MediaBox, el TrimBox, el sangrado y las marcas de corte del programa —un solo MediaBox en todo el PDF, verificado—. Y como la superposición tapaba las marcas de corte, se repintan encima como un Form XObject generado al vuelo, solo en las páginas cerradas.
La jornada se cerró con dos ajustes de imprenta con criterio de taller. Los materiales cerrados ahora respetan su posición en el listado —el renderizado reserva una página marcador invisible, señalada con un texto transparente, y después superpone encima el material del cliente con sangrado— y el múltiplo de 4 se calcula con las páginas marcador ya dentro. Además, la exportación incorpora dos opciones: «Textos en negro puro (solo plancha K)», que define la tinta como device-cmyk(0,0,0,1) y que esta sobrevive intacta a la conversión de Ghostscript, y la reducción de imágenes por encima del mínimo configurado (300 ppp por defecto) durante la conversión. La revalidación final con todo plegado volvió a dar el informe completamente en verde. La funcionalidad queda lista para validar con el usuario y hacer la fusión.