¿Qué es un PDF linealizado? El trasfondo técnico de la visualización web rápida
8 min de lectura
De dos PDF del mismo tamaño, uno se abre al instante en el navegador y el otro muestra una página en blanco hasta que baja del todo. La diferencia no está en el contenido del archivo, sino en la disposición de los objetos dentro de él. En este artículo explicamos el mecanismo de lectura del PDF, cómo la linealización lo invierte y para qué sirven las tablas de pistas.
Por qué el PDF se lee desde el final
Al final de un archivo PDF hay estas tres cosas:
startxref
1247893
%%EOF
La línea startxref indica en qué byte del archivo empieza la tabla de referencias cruzadas. Lo primero que hace un visor al abrir un PDF es leer los últimos cientos de bytes del archivo para encontrar ese número.
Después va a ese byte y lee la tabla xref. Esa tabla lista el número de cada objeto del archivo y el byte en el que empieza. Tras la tabla viene además un diccionario trailer, donde figura el número del objeto catálogo.
Ya puede el visor encontrar el catálogo. Del catálogo pasa al árbol de páginas, del árbol de páginas al objeto de la primera página y de ahí al flujo de contenido y a los recursos que usa. Esos recursos pueden estar en cualquier punto del archivo: la tipografía de la primera página puede estar en el medio y su imagen, casi al final.
Este diseño tiene una razón: la actualización incremental. Cuando se modifica un PDF, en lugar de reescribir todo el archivo se añaden los cambios al final y se escribe una tabla xref nueva. La tabla nueva apunta a la antigua diciendo "para lo que no ha cambiado, mira ahí". El archivo crece, pero la operación es rápida y la versión anterior sigue dentro del archivo. La lógica de funcionamiento de las firmas digitales también se apoya en esto.
El precio es este: no puedes leer ninguna parte del archivo sin haber visto antes su final.
Por qué eso es un problema en la red
En un disco local, saltar al final del archivo se considera gratis. En la red la cosa cambia.
Si un navegador pide un PDF al servidor, el servidor empieza a enviar el archivo desde el principio. Pero la información que necesita el visor está justo al final. Es decir, para poder dibujar la primera página hay que esperar en la práctica a que baje el archivo entero.
Un catálogo de 50 MB tarda unos 40 segundos en una conexión de 10 Mbps. El usuario mira una página en blanco durante esos 40 segundos. La mayoría no espera.
La linealización invierte la disposición
La estructura de un PDF linealizado es así:
| Posición | Contenido |
|---|---|
| Principio del archivo | Diccionario de parámetros de linealización (/Linearized) |
| Justo después | Tabla xref y trailer de la primera página |
| Después | Todos los objetos de la primera página (contenido, tipografía, imagen) |
| Después | Tablas de pistas (hint tables) |
| Después | Los objetos de las demás páginas, en orden de página |
| Final del archivo | Tabla xref principal (por compatibilidad) |
El diccionario de parámetros del principio del archivo dice esto: este archivo está linealizado, su longitud total es esta, los objetos de la primera página llegan hasta este byte, las tablas de pistas empiezan aquí.
Gracias a eso, en cuanto el visor recibe los primeros cientos de kilobytes del archivo ya tiene todo lo necesario para dibujar la primera página. El usuario empieza a leerla mientras la descarga continúa.
Tablas de pistas: la estructura que permite saltar de página
El segundo beneficio de la linealización, quizá más valioso, es poder saltar directamente a la página que se quiera.
Lo que lo hace posible son las tablas de pistas. Hay dos:
Tabla de Pistas de Desplazamiento de Página (Page Offset Hint Table): para cada página, indica en qué byte del archivo empiezan sus objetos y cuántos bytes ocupan. Cuando el usuario salta a la página 147, el visor consulta esta tabla, obtiene el dato de que "la página 147 está entre los bytes 8.234.100 y 8.291.000" y pide al servidor solo ese rango.
Tabla de Pistas de Objetos Compartidos (Shared Object Hint Table): lista los recursos que comparten varias páginas, como las tipografías incrustadas que se usan a lo largo del documento o un logotipo que se repite en cada página. Si la página 147 necesita alguno de ellos, el visor también obtiene aquí su rango de bytes.
Resultado: en un archivo de 500 páginas y 80 MB, ver la página 147 requiere descargar apenas unos cientos de kilobytes.
Byte-range: la condición del lado del servidor
El mecanismo anterior se basa en que el navegador pueda decirle al servidor "dame los bytes del 8.234.100 al 8.291.000 de este archivo". En HTTP eso se hace con la cabecera Range y el servidor debe responder con 206 Partial Content.
Casi todos los servidores web modernos lo admiten para archivos estáticos y suele estar activado por defecto. Pero no funciona en estos casos:
- Si el archivo se genera dinámicamente (si un servidor de aplicaciones crea el PDF al vuelo), normalmente no hay soporte de byte-range.
- Si la respuesta se comprime con gzip, los rangos de bytes pierden sentido. Como los PDF ya vienen comprimidos por dentro, aplicar además gzip en el servidor es innecesario y genera este problema.
- Algunas configuraciones de CDN o proxy pueden no dejar pasar las peticiones de rango.
Si se da alguna de estas condiciones, aunque el archivo esté linealizado el navegador tendrá que descargarlo entero y el beneficio desaparece.
Lo que la linealización no cambia
Conviene dejar este punto claro porque existe un malentendido frecuente:
El tamaño del archivo. La linealización no descarta ningún contenido ni recodifica ninguna imagen. Como se añaden las tablas de pistas, el archivo crece típicamente entre un 1 y un 2 %. Si quieres reducirlo, necesitas compresión.
La calidad de imagen. No cambia ni un píxel.
El texto, las tipografías, la maquetación. Nada de eso se ve afectado.
La velocidad de apertura en local. Si el archivo ya está en el disco, el orden no importa; un archivo linealizado no se abre más rápido en local.
Cuándo se estropea la linealización
Un archivo linealizado puede perder esa propiedad cuando se opera sobre él:
Cualquier operación con actualización incremental lo estropea. Añadir una anotación, rellenar un campo de formulario, poner una firma digital: la mayoría de esas acciones añaden los cambios al final del archivo. El archivo sigue siendo válido, pero ahora el visor necesita mirar al final para conocer el estado actual, y la promesa de la linealización deja de tener efecto.
Las operaciones que reescriben el archivo entero también lo estropean: comprimir, añadir o borrar páginas, combinar, dividir. Estas generan el archivo desde cero y la disposición linealizada especial no se conserva.
Consecuencia práctica: la linealización debe ser el último paso del flujo de trabajo. Comprime, edita, firma, haz lo que tengas que hacer y, al final, lineariza y publica.
Cómo comprobarlo
La forma más simple de saber si un archivo está linealizado es mirar sus primeros bytes. En un PDF linealizado, el primer objeto es parecido a esto:
1 0 obj
<< /Linearized 1 /L 1247893 /O 6 /E 45231 /N 120 /T 1247100 >>
endobj
La clave /Linearized 1 es la prueba directa. /N da el número total de páginas, /L la longitud del archivo y /O el número del objeto de la primera página.
Para probarlo en condiciones reales, sube el archivo al servidor y ábrelo con la simulación de conexión lenta de las herramientas de desarrollo del navegador. En un archivo linealizado, la primera página aparece antes de que termine la descarga.
En resumen
El PDF coloca la tabla de referencias cruzadas al final del archivo para permitir las actualizaciones incrementales, y eso implica esperar al archivo entero cuando se lee a través de la red. La linealización invierte la disposición: todo lo de la primera página pasa al principio y se añaden tablas de pistas que indican dónde está cada página. Así, la primera página aparece de inmediato y se puede saltar directamente a cualquier página, siempre que el servidor admita peticiones byte-range. La operación no reduce el tamaño del archivo, no cambia la calidad y no acelera la apertura en local. Solo tiene sentido en archivos grandes publicados en la web y, como se estropea si se hace cualquier otra operación sobre el archivo, debe aplicarse como último paso.
Preguntas frecuentes
¿Por qué en un PDF normal el visor tiene que mirar al final del archivo?
Porque el formato PDF coloca al final del archivo la tabla de referencias cruzadas (xref), que indica en qué parte del archivo está cada objeto. Esa decisión de diseño existe para permitir actualizaciones incrementales: los cambios nuevos se añaden al final y se escribe una xref nueva sin estropear la anterior. El precio es tener que empezar a leer por el final.
¿Qué contiene exactamente una tabla de pistas (hint table)?
Hay dos tablas principales. La Tabla de Pistas de Desplazamiento de Página indica en qué rango de bytes del archivo están los objetos de cada página. La Tabla de Pistas de Objetos Compartidos indica dónde están los recursos que comparten varias páginas (tipografías, imágenes repetidas). Al saltar a una página, el visor consulta esas dos tablas y pide solo los rangos de bytes necesarios.
¿Un archivo linealizado se abre también en los visores normales?
Sí, sin ningún problema. La linealización forma parte del estándar y un archivo linealizado es al mismo tiempo un PDF normal válido: al final del archivo sigue habiendo una tabla xref. Un visor que no entienda la linealización lee el archivo por el método clásico sin ninguna dificultad. Se pierde el beneficio, pero no la compatibilidad.
¿Por qué una actualización incremental estropea la linealización?
Porque la promesa básica de la linealización es que todo lo necesario para dibujar la primera página está al principio del archivo. Una actualización incremental añade los cambios al final y escribe una xref nueva; a partir de ahí, el visor necesita mirar al final para conocer el estado actual. El archivo sigue siendo válido, pero la garantía de visualización web rápida deja de tener efecto.
Pruébalo ahora mismo con Web İçin Optimize Et.
Probar Web İçin Optimize Et