# Introducción a Postext

> Qué es Postext, por qué existe y el problema que resuelve

- Versión HTML: https://postext.dev/es/docs/introduction
- Última actualización: 2026-10-26
- Tiempo de lectura: 7 min
- Otros idiomas: [en](https://postext.dev/en/docs/introduction.md), [ca](https://postext.dev/ca/docs/introduction.md), [de](https://postext.dev/de/docs/introduction.md), [fr](https://postext.dev/fr/docs/introduction.md), [it](https://postext.dev/it/docs/introduction.md), [pt](https://postext.dev/pt/docs/introduction.md), [zh](https://postext.dev/zh/docs/introduction.md), [ja](https://postext.dev/ja/docs/introduction.md), [ar](https://postext.dev/ar/docs/introduction.md)

## En pocas palabras

Postext es un programa libre y gratuito que compone las páginas de libros, revistas e informes en la web. Los libros impresos siguen desde hace siglos reglas de maquetación muy cuidadas, como igualar las columnas o poner cada imagen cerca del texto que la menciona. Las páginas web nunca han tenido esas reglas, y Postext las añade. Tú escribes el texto y Postext coloca en la página cada línea, imagen y nota. Esta página cuenta por qué existe el proyecto y cómo empezó.

**Un compositor tipográfico programable para la web.**

Abre cualquier libro bien compuesto. Fíjate en cómo se asienta el texto en la página: columnas
perfectamente equilibradas, imágenes integradas en el texto, sin huecos torpes ni líneas sueltas
abandonadas en lo alto de una columna. Detrás de esa aparente naturalidad hay siglos de oficio.

Ahora abre una página web. Hasta las mejores dan otra impresión. El texto choca con las imágenes.
Las columnas se desbordan o se quedan a medio llenar. Las notas al pie se van al final de la página
en lugar de quedarse cerca de las palabras que las llaman. La web nos dio la maquetación adaptable,
pero nunca nos dio maquetación *editorial*.

Postext cierra esa brecha. Es un motor de maquetación que recibe tu contenido (texto en Markdown y
recursos declarados, como imágenes de mapa de bits, diagramas SVG, tablas y vídeos, que se incorporan por
referencia) y le aplica las mismas reglas que aplicaría un tipógrafo profesional: evitar huérfanas y
viudas, equilibrar las columnas, hacer que el texto rodee los obstáculos y espaciar con intención.
El resultado es una geometría de página con calidad editorial, que se dibuja en canvas, HTML, PDF,
EPUB o como libro en 3D.

Se apoya en [`@chenglou/pretext`](https://github.com/chenglou/pretext), que mide el texto sin el DOM
a una velocidad que hace posible todo esto.

## La brecha entre la imprenta y la web

Durante siglos, los tipógrafos han seguido reglas que hacen que el texto sea agradable de leer. No
son preferencias estéticas, sino principios aprendidos a base de esfuerzo y depurados durante
generaciones de libros, periódicos y revistas:

- Nada de huérfanas (una sola línea de un párrafo aislada en lo alto de una columna).
- Nada de viudas (una sola línea de un párrafo abandonada al pie de la columna).
- Columnas equilibradas (de altura parecida en toda la doble página).
- Texto que rodea las figuras, los destacados y las imágenes insertadas.
- Notas al pie colocadas al final de la columna en la que se llaman.
- Notas al margen alineadas con el párrafo que las cita.
- Espaciado coherente e intencionado alrededor de encabezados, citas y figuras.
- Separación silábica que evita los ríos y los bordes demasiado irregulares.

Más allá de estas reglas, hay dos magnitudes concretas y medibles que muestran cuánto se aleja la
web de la imprenta:

- **Medida (ancho de línea).** Bringhurst sitúa el intervalo cómodo entre **45 y 75 caracteres** por
  línea en una sola columna (y entre **40 y 50** cuando hay varias); la pauta de accesibilidad [WCAG
  1.4.8](https://www.w3.org/WAI/WCAG21/Understanding/visual-presentation.html) la limita a 80. La
  mayoría de las webs dejan que las líneas lleguen a 100, 120 o más, muy por encima del punto en el
  que el ojo puede seguir una línea sin perderse.
- **Interlineado.** La tradición recomienda **entre 1,3 y 1,5 veces el cuerpo de la letra**, y [WCAG
  1.4.12](https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html) exige que el contenido siga
  funcionando con 1,5 o más. Pero el valor adecuado depende de la medida: un interlineado que se lee
  bien con 50 caracteres resulta apretado con 90. Los tipógrafos ajustan uno en función del otro;
  CSS no ofrece ninguna forma automática de hacerlo.

Y aquí CSS se queda corto: tienes `column-count` y poco más. No hay control sobre la colocación de
los recursos, ni detección del desbordamiento, ni forma de evitar huérfanas y viudas de una columna
a otra, ni una manera nativa de hacer que el texto rodee un obstáculo cualquiera. En la web, las
maquetaciones editoriales a varias columnas siguen haciéndose a mano: diseños estáticos que se
rompen en cuanto cambia el tamaño de la pantalla.

La web tiene maquetación adaptable desde hace más de una década: flexbox, grid, contenedores que se
ajustan a cualquier pantalla. Lo que nunca ha tenido es maquetación *editorial* adaptable, aquella
en la que el contenido se recoloca con inteligencia por las columnas, alrededor de las imágenes y
entre las notas al pie, respetando las reglas que hacen que el texto sea *agradable de leer*.

> **Figura: La brecha entre CSS multicolumna y la maquetación editorial**
> CSS ofrece column-count y poco más; la maquetación editorial necesita control de huérfanas y viudas, flujo alrededor de obstáculos, equilibrado de columnas, colocación de notas al pie y refinamiento por convergencia.
>
> *Lo que CSS ofrece frente a lo que la maquetación editorial realmente necesita.*

## Una década buscando la pieza que faltaba

El proyecto [Content
First](https://medium.com/binpar/el-arte-de-maquetar-para-ser-le%C3%ADdo-933be57cb293) nació en 2014
como uno de los primeros intentos de llevar a la web la calidad de la maquetación editorial.
Maquetaciones en columnas, experimentos con el flujo del texto, prototipos sucesivos… y siempre el
mismo muro: **no se pueden tomar buenas decisiones de maquetación sin saber exactamente cuánto
espacio va a ocupar el texto.**

Parece sencillo, pero ahí está todo el problema. Cada vez que preguntas al navegador «¿qué altura
tiene este párrafo con este ancho?», provocas un recálculo completo de la maquetación (un *reflow*).
Hazlo unos cientos de veces en un documento complejo a varias columnas y la página se congela. El
navegador nunca se diseñó para este tipo de medición especulativa: probar diez anchos de columna
distintos para quedarse con el mejor, ensayar dónde cortar un párrafo o comprobar si una imagen cabe
aquí o tiene que pasar a la columna siguiente.

Faltaba una forma de medir el texto lo bastante rápida como para experimentar con libertad, sin
bloquear el hilo principal. Durante una década, esa herramienta no existió.

## La pieza que faltaba

En 2025, Cheng Lou publicó [`Pretext`](https://github.com/chenglou/pretext): una biblioteca que mide
texto sin el DOM, entre 300 y 600 veces más rápida que el *reflow* del navegador y exacta al píxel
en Chrome, Safari y Firefox. Calcula la altura del texto y dónde se corta cada línea con las
métricas de fuente del canvas y simple aritmética, sin tocar nunca el DOM.

Con Pretext desaparece el cuello de botella que bloqueó este trabajo durante diez años. Puedes medir
miles de bloques de texto en milisegundos, probar diez configuraciones de columnas distintas y
quedarte con la mejor, o ejecutar el algoritmo de maquetación completo cada vez que cambia el tamaño
de la ventana, sin bloquear el hilo principal.

Postext es lo que viene después.

## Pretext + Postext

El nombre no es casual: son dos mitades de la misma operación. Separarlas importa porque son
responsabilidades distintas (una mide y la otra decide), y aislar la medición permite que cualquier
backend la use sin atarse a las reglas editoriales.

**Pretext** es lo que ocurre *antes* de colocar el texto: medir cuánto espacio va a necesitar. Sin
DOM, basado en canvas, solo con números.

**Postext** es lo que ocurre *después* de medir: las decisiones editoriales. Con las dimensiones
exactas de cada bloque de texto a cualquier ancho, el motor decide dónde va cada elemento: en qué
columna, en qué posición, alrededor de qué recursos fluye y qué reglas tipográficas respeta.

```ts
import { prepare, layout } from '@chenglou/pretext';
import { buildDocument, renderToCanvas, renderToHtml } from 'postext';
import { renderToPdf } from 'postext-pdf';

// pretext: medir (el trabajo "pre")
const prepared = prepare(paragraphText, '16px/1.5 Inter');
const { height } = layout(prepared, columnWidth, 24);
// => "Este párrafo mide 144px de alto a este ancho de columna."

// postext: decidir (el trabajo "post")
const vdt = buildDocument(content, config);
// => Un Árbol Virtual del Documento completo con cada párrafo,
//     encabezado y recurso colocados en coordenadas exactas.

// Un único VDT, tres modos de salida:
const canvases = renderToCanvas(vdt);                       // bitmap pixel-perfect por página
const html = renderToHtml(vdt);                             // DOM seleccionable para la web
const pdfBytes = await renderToPdf(vdt, { fontProvider });  // PDF listo para imprimir
```

Pretext te da las medidas. Postext te da la maquetación.

> **Figura: Pretext mide, Postext decide**
> Pretext mide el texto con canvas, sin DOM. Postext usa esas medidas exactas para decidir la columna y la posición, el flujo alrededor de los recursos y las reglas de huérfanas, viudas y equilibrado.
>
> *Dos mitades de la misma operación: Pretext antes, Postext después.*

*Pretext es obra de [Cheng Lou](https://github.com/chenglou). Postext se construye sobre él.*

## Cómo funciona

El proceso tiene tres etapas:

1. **Tú aportas el contenido.** Texto en Markdown y recursos declarados: imágenes de mapa de bits,
   diagramas SVG, tablas y vídeos. Una referencia en línea `:ref{id="..."}` numera el recurso y, a la vez,
   lo coloca como flotante en una banda superior o inferior cerca de su primera mención, igual que
   un tipógrafo coloca las figuras en un libro impreso. El contenido sigue siendo puramente
   semántico: describe *qué* se presenta, no *cómo*; las decisiones de maquetación nunca quedan
   fijadas en el texto de origen. La sección sobre recursos de
   [Formato del documento](https://postext.dev/es/docs/document-format.md) recoge la sintaxis completa.

2. **El motor toma las decisiones.** Postext analiza el contenido, pide a Pretext medidas exactas al
   píxel sin tocar el DOM y después ejecuta un proceso de maquetación en varias pasadas: equilibra
   las columnas, numera los recursos y los coloca como flotantes, evita viudas y huérfanas, alinea
   las líneas base y afina el espaciado. Cada decisión depende de la configuración: la geometría de
   la página y de la maquetación, el texto base y los encabezados, además de `tableStyle` para la
   tipografía de las celdas de tabla, `captionStyle` para los pies de figura y `diagramStyle` con
   `singleInk`, que vuelve a colorear los diagramas SVG con matices de una sola tinta según su
   luminancia, para imprimir con una única tinta directa. Tú defines las reglas y el motor las
   aplica.

3. **Obtienes una maquetación completa.** Coordenadas y dimensiones precisas de cada elemento en
   cada página. Los renderizadores trasladan esa geometría al formato de destino: **canvas** para
   una vista previa en mapa de bits exacta al píxel (`renderToCanvas`, `renderPage`), **HTML** para
   una tipografía seleccionable en la web que responde a los cambios de tamaño (`renderToHtml`,
   `renderToHtmlIndexed`), **PDF** para una salida lista para imprenta, con las fuentes incrustadas
   (`renderToPdf`, del paquete `postext-pdf`), **EPUB 3** para los lectores de libros electrónicos
   (`renderToEpub`, de `postext-epub`), paquetes **SCORM** con ejercicios que envían sus resultados a
   una plataforma de aprendizaje (`renderToScorm`, de `postext-scorm`) y un **libro en 3D** cuyas
   hojas se pasan en el navegador (`createFolioFromDocument`, de `postext-folio`). Todas las salidas
   se dibujan a partir de la misma maquetación.

> **Figura: Maquetación en tres etapas**
> El Markdown enriquecido y la configuración entran en el motor, que maqueta en varias pasadas, con la medición de Pretext dentro, y genera el HTML o el PDF.
>
> *Entra contenido y sale geometría, que después se convierte al formato de destino.*

Si quieres ver en detalle cómo funciona el motor por dentro (el Árbol Virtual del Documento, el
proceso en varias pasadas y el bucle de convergencia), consulta
[Arquitectura](https://postext.dev/es/docs/architecture.md). La referencia completa de todas las opciones de
configuración, desde la geometría de la página hasta el estilo de tablas, pies de figura y
diagramas, está en [Configuración](https://postext.dev/es/docs/configuration.md). Y para probarlo todo en directo (un
editor para el texto de cada capítulo, un panel **Recursos** con editor de tablas y subida de
imágenes y SVG, un panel **Diseño** que recorre todos los ajustes en términos editoriales, vistas
previas en vivo en canvas, PDF, Folio (3D), HTML y EPUB, y una exportación a SCORM), abre el
[Sandbox](https://postext.dev/es/docs/sandbox.md).

## Reconocimientos

**[Pretext](https://github.com/chenglou/pretext)**, de Cheng Lou: la biblioteca de medición de texto
en la que se basa Postext. Sin una medición fuera del DOM, exacta al píxel y en menos de un
milisegundo, nada de esto sería viable.

**Content First** (~2014): la primera exploración de la maquetación editorial de calidad en la web.
Una década de toparse con muros, de aprender qué no funciona y de convencerse de que este problema
merece una solución de verdad.

Postext se apoya en siglos de tradición tipográfica. Las reglas que aplica no son inventadas: las ha
heredado del trabajo de cajistas, tipógrafos y diseñadores que perfeccionaron el arte de hacer
legible el texto mucho antes de que existieran las pantallas. De los tipos móviles de Gutenberg a la
tipografía asimétrica de Tschichold y los *Elementos del estilo tipográfico* de Bringhurst, el
oficio de disponer el texto en la página lleva más de quinientos años evolucionando. Postext lleva a
la web esa sabiduría acumulada, que hasta ahora brillaba por su ausencia.