Contribuir a Postext

Construyamos juntos el motor de maquetación editorial que la web nunca ha tenido.

Postext es un proyecto de código abierto impulsado por su comunidad. Quiere resolver un problema que lleva décadas sin resolverse: llevar la maquetación editorial profesional a la web. Es una ambición grande, y no está al alcance de una sola persona.

El proyecto es joven, pero ya no parte de cero: el proceso de composición, el formato de documento y el sistema de configuración ya están publicados. Aun así, quedan muchas decisiones de diseño por tomar, y quienes se incorporan ahora pueden influir de verdad en el rumbo del proyecto. Si estabas esperando el momento oportuno para unirte, es este.

No hace falta ser programador para colaborar. Tanto si escribes código como si diseñas maquetaciones editoriales, sabes de tipografía, pruebas en distintos navegadores, redactas documentación, traduces o simplemente tienes ideas sobre cómo debería funcionar el contenido editorial en la web, aquí hay sitio para ti.

#Por qué contribuir

Todos los equipos de desarrollo editorial del mundo se topan con el mismo problema: CSS no se diseñó para la maquetación editorial. No ofrece de forma nativa el equilibrado de columnas, el control de huérfanas y viudas, el texto que fluye alrededor de obstáculos ni la colocación de las notas al pie. Cada equipo resuelve estos problemas desde cero, con soluciones frágiles y hechas a medida, caras de mantener e imposibles de compartir.

Postext quiere cambiar eso. No como una herramienta propietaria, sino como un estándar abierto y compartido: un único motor de maquetación de alta calidad que editoriales, revistas, periódicos, plataformas de libros y equipos de desarrollo de todo el mundo puedan adoptar y ampliar.

Un estándar así no lo puede construir una sola persona ni una sola empresa. Necesita la mirada de tipógrafos de distintas tradiciones, especialistas en PDF, expertos en accesibilidad, desarrolladores que trabajen con escrituras de derecha a izquierda, diseñadores que maqueten revistas e ingenieros que optimicen el rendimiento del renderizado. La diversidad del mundo editorial exige una comunidad igual de diversa detrás de la herramienta que lo sirve.

#Cómo trabajamos

Toda la coordinación se hace en GitHub. No hay canales privados, ni listas de correo cerradas, ni decisiones tomadas a puerta cerrada. Todo es público, se puede buscar y está abierto a la participación.

• Issues: para informar de errores, pedir funciones y proponer tareas concretas. Si quieres trabajar en algo, empieza por aquí.
• Pull Requests: para aportar código. Antes de escribirlo, abre un issue para hablar del enfoque.
• Discussions: para ideas, conversaciones de diseño, preguntas y todo lo que no sea un error o una tarea concretos. Es el lugar para pensar en voz alta.

Es una decisión deliberada: si todo está en un solo sitio, cualquiera puede encontrar el contexto de cada decisión, y quien llega nuevo puede leer el historial.

#Áreas donde puedes ayudar

El proyecto necesita perfiles muy distintos. Estas son algunas áreas en las que las aportaciones son especialmente valiosas:

#Código y algoritmos

• Algoritmos de composición tipográfica: el motor de justificación Knuth-Plass, el equilibrado de columnas, el corte óptimo de párrafos, la numeración de recursos por tipo y la colocación de flotantes.
• Generación de PDF: construcción de PDF a bajo nivel, incrustación de fuentes, gestión del color y tratamiento de los bytes de los recursos para las figuras de tinta única.
• Renderizado de texto: renderizado en canvas, salida SVG, recoloreado de SVG en tinta única (diagramStyle.singleInk) y métricas de fuente.
• Optimización del rendimiento: la capa de caché de mediciones, el algoritmo de cortes de línea Knuth-Plass escrito en Rust y compilado a WebAssembly (rust/), y el reto de que el motor siga siendo lo bastante rápido para trabajar en tiempo real cada vez que cambia el tamaño.

#Sandbox e interfaz

El Sandbox se ha convertido en una aplicación React considerable por derecho propio: un panel Recursos con un editor interactivo de tablas y subida de imágenes y SVG, un panel Fuentes, editores de plantillas de página y de páginas de cómic, y un panel Diseño cuyos grupos cubren todas las partes del motor. Sus controles se construyen sobre los componentes básicos de Base UI (packages/postext-sandbox/src/ui/) y se revisan con axe-core y con comprobaciones propias según WCAG 2.2 en el nivel AAA, así que los controles nuevos deben reutilizarlos y procurar que cada campo tome su nombre de su etiqueta y su descripción de su texto de ayuda. Todas las cadenas de la interfaz siguen una convención estricta de i18n: cada etiqueta se conecta en el paquete del Sandbox, en el puente de etiquetas de la aplicación web y en el catálogo de cada uno de los diez idiomas. Si colaboras en el frontend o en la experiencia de usuario, este es tu terreno.

#Diseño y tipografía

• Experiencia en diseño editorial: si has maquetado revistas, periódicos o libros, lo que sabes sobre por qué una maquetación funciona (o falla) es valiosísimo, y no hace falta escribir código.
• Tradiciones tipográficas: el proyecto debe respetar las convenciones tipográficas de los distintos idiomas y sistemas de escritura, no solo las de la escritura latina.

#Documentación y comunidad

• Documentación: mejorar, ampliar y mantener la documentación. Una documentación clara marca la diferencia entre un proyecto que la gente adopta y uno que abandona.
• Traducciones: la documentación y el sitio están en diez idiomas: inglés, español, catalán, francés, alemán, italiano, portugués de Brasil, chino simplificado, japonés y árabe. Cualquier idioma nuevo es bienvenido, y también las revisiones de los que ya hay.
• Pruebas: probar en distintos navegadores, sistemas operativos y casos límite. Encontrar las maquetaciones que se rompen vale tanto como construir las que funcionan.

#Diseño de formato y esquema

El formato ya no es una hoja en blanco: los bloques ::resource, las referencias en línea :ref y las secciones de configuración tableStyle, captionStyle y diagramStyle ya están publicados. Ahora se trata de hacer evolucionar un formato asentado sin romperlo:

• Gramática del documento: las notas al margen siguen siendo una cuestión abierta, tanto de diseño como técnica.
• Esquema de configuración: que el sistema siga siendo lo bastante potente para los profesionales y lo bastante sencillo para los recién llegados a medida que crece.

#Primeros pasos

La puesta a punto práctica (clonar el repositorio, instalar las dependencias, ejecutar las pruebas) se explica en CONTRIBUTING.md. Empieza por ahí para los pasos mecánicos.

Una vez que lo tengas todo listo, aquí tienes tres pasos concretos, de menor a mayor compromiso:

1. Preséntate en Discussions: cuenta en qué trabajas y qué te ha traído hasta aquí. Ninguna pregunta es demasiado básica, y es la forma más rápida de que la comunidad sepa que has llegado.
2. Elige un issue etiquetado como good first issue: están seleccionados para ser un punto de entrada realista, sin necesidad de conocer la historia del proyecto.
3. Traduce la documentación a un idioma nuevo, o revisa uno: hoy la documentación está en diez idiomas. Cada idioma nuevo llega a lectores que no pueden leer los demás.

Si piensas escribir código, abre antes un issue para hablar del enfoque: así se evita el trabajo duplicado, y una conversación breve al principio ahorra tiempo a todos.

Mantén cada archivo de código por debajo de unas 600 líneas y cada carpeta por debajo de unos 25 archivos de código: un módulo que crece más se convierte en una carpeta con su mismo nombre, y el archivo antiguo queda como fachada que la reexporta. La CI comprueba los límites con node scripts/source-size.mjs --check (ver Code Layout en CONTRIBUTING.md).

#Qué leer después

Para orientarte antes de lanzarte:

• Arquitectura: cómo se organiza el proceso de composición y dónde está cada subsistema.
• Formato del documento: la gramática de Markdown enriquecido que amplían los colaboradores.
• Sandbox: el banco de pruebas donde resulta más fácil ver y probar la mayoría de los cambios.

#La comunidad

Postext todavía está empezando, y eso es justo lo que hace especial este momento. Quienes se incorporan ahora no solo escriben código: están dando forma a las convenciones, las prioridades y la cultura del proyecto.

El proyecto valora:

• El diseño meditado por encima de la velocidad. Acertar con las abstracciones importa más que publicar deprisa. La tipografía se ha ido refinando durante siglos; podemos tomarnos el tiempo necesario para hacerlo bien.
• La claridad por encima del ingenio. Un código fácil de leer y de entender vale más que uno impresionante pero opaco.
• La colaboración por encima del territorio. Nadie es dueño de una parte del código. Las ideas se valoran por sus méritos, no por quién las propone.

Todos los colaboradores reciben reconocimiento. Este proyecto existe porque hay personas que deciden dedicar su tiempo a mejorarlo.

#Visión

Postext aspira a convertirse en el motor de maquetación de referencia para el contenido editorial en la web: la herramienta a la que recurran editoriales, revistas, periódicos y plataformas de libros cuando necesiten una tipografía profesional.

Si trabajas en desarrollo editorial y llevas tiempo resolviendo estos problemas de maquetación por tu cuenta, esta es tu invitación a resolverlos de una vez, bien y en compañía.