Páginas adaptables: de la especificación a producción en un día

El día empezó con una revisión de 14 rondas y 45 decisiones sobre la funcionalidad que tenía en mente: que el motor eligiera la maquetación de cada artículo según su contenido, la verificara midiendo el renderizado y se corrigiera si no cabía. La idea central: la Página adaptable es una entidad nueva, no una plantilla más. Unas reglas de ajuste (palabras del cuerpo, número de imágenes contando la destacada y orientación de esta), un rango de páginas previsto y un CSS propio con ámbito automático.

Primero medir, después decidir

Medí cada decisión que tenía una alternativa técnica antes de formularla. Las páginas con nombre rompían el flujo continuo, así que las variantes no pueden llevar un @page propio. El anidamiento de CSS sí funciona con WeasyPrint 70, lo que levantó una limitación que ya había comunicado. Page.anchors es público y hace trivial la medición de la extensión. Una de esas mediciones destapó una contradicción entre dos decisiones ya tomadas: con las variantes precargadas con rango abierto y una corrección que se quedaba con la primera que encajara, la primera de la lista se habría llevado todos los artículos. La salida: al corregir, gana el rango más concreto y el rango abierto es el comodín final.

La especificación salió como la incidencia #7 del rastreador, con siete tareas pendientes como subincidencias y dependencias nativas de GitHub. El límite era la incidencia #8: a partir de ahí se podía empezar.

Siete balizas trazadoras en un día

La primera (#8) dejó lista la tabla, la sección de Configuración y cuatro variantes precargadas, con la predeterminada al final como reserva: sus reglas son abiertas y fijas, porque, de lo contrario, algún artículo se quedaría sin destino. La segunda (#9) puso el motor en marcha: calcula las señales de cada artículo, elige la primera variante que encaja e inyecta su CSS después de la hoja de estilos maestra, con el anidamiento proporcionandom el ámbito automáticamente. La tercera (#10) añadió la medición por artículo dentro de sus propios bucles y de la corrección, hasta dos veces, avisando si no se cumplía el rango. Con estas tres, actualicé producción y reconstruí el contenedor.

Después llegaron el CRUD completo (#12), con el nombre como identidad fija de la variante y el borrado en Neteja; la vista previa como función pura y la asignación manual que prevalece sobre el motor (#11); y la exportación a InDesign fiel al PDF (#13), que arrastraba un error del código .jsx: guardaba los estilos por rol y dos artículos con el mismo rol salían con el mismo estilo. Ahora se identifican por su definición. El cierre (#14) fue el recorrido completo con el material real de la edición n2, no con material de prueba.

Calibrar con el material real

Los tres artículos de la n2 tienen 174, 318 y 395 palabras y ocupan 1,43, 2,29 y 2,20 páginas. El corte de 250 palabras queda confirmado. Ningún material respeta el de 800 y Larga pasa a 500. Y la capacidad de referencia de la investigación (500-700 palabras por página) queda refutada cuando se incluyen fotos: la medición real es de 150-200 palabras por página. En el código queda la medición, no la cifra en papel.

Panel y coste

Las plantillas libres ya pueden elegirse como pieza de cada artículo, y el panel muestra en una etiqueta qué tiene asignado; de paso, apareció un atributo hidden que no ocultaba nada debido a un display: flex, corregido con la regla estándar. También medí el coste del bucle de corrección con el número real: 0,71 s sin correcciones, 1,45 s con las dos correcciones y cada renderizado adicional cuesta unos 0,37 s. La batería cerró el día con 255 pruebas en verde.