Qué ocurre realmente al comprimir un PDF
Compress de PDF123 recompone los streams con qpdf y empaqueta los objetos en object-streams: nada de reducir la resolución de las imágenes, nada de recodificar a JPEG con pérdida, nada de subsetting de fuentes. La linearización apenas cambia el tamaño del archivo.
Dos PDF pueden verse idénticos en pantalla y diferenciarse en tres órdenes de magnitud: 50 KB frente a 50 MB. La brecha casi nunca está en los operadores de texto. En un contrato de veinte páginas esos operadores suelen ocupar unas pocas decenas de kilobytes; todo lo demás son muestras de imagen, un programa de fuente embebido por completo y lo apretado que estén los streams y los objetos.
Eso tiene una consecuencia que conviene enunciar desde el principio: «comprimir un PDF» no es una sola acción, sino cuatro. Encogen cosas distintas y cobran precios distintos, y tratarlas como una sola produce experiencias contradictorias: el archivo comprimido que no se redujo, o reducido pero con las páginas emborronadas.
El tamaño viene de las imágenes, las fuentes y el empaquetado
La mayoría de los casos de «¿por qué este PDF es enorme?» empiezan con un escaneo o una foto de alta resolución aún embebidos a su tamaño de captura. Merece la pena hacer la aritmética una vez: una página tamaño carta de 8,5 × 11 pulgadas capturada a 300 DPI son unos 2550 × 3300 píxeles y, a tres bytes por píxel, unos 25 MB sin comprimir. Veinte páginas así suelen llegar a 60–80 MB antes de que nadie toque la compresión.
El segundo origen son las fuentes tipográficas. Un PDF puede embeber un programa de fuente entero para que cualquier máquina renderice el texto igual, y ese coste se mide por el tamaño de las tablas de glifos, no por cuánto texto se lee de verdad. Por eso el subsetting de fuentes es una palanca de tamaño aparte.
El tercero es el empaquetado en sí. Un mismo contenido puede almacenarse con ajustes de compresión derrochadores, o sus objetos pueden quedar dispersos por el archivo, cada uno con su propia contabilidad. Nada de eso cambia un solo píxel ni un solo glifo, y es justo la parte que la recompresión de streams sí alcanza.
«Comprimir» abarca cuatro palancas distintas
Hay cuatro palancas sobre el tamaño; actúan en capas distintas y sus costes apenas se solapan. Elegir la equivocada es la razón más frecuente de que una compresión parezca no hacer nada.
| Palanca | Qué toca | Ganancia de tamaño | Coste |
|---|---|---|---|
| Recompresión de streams y object-streams | Cómo se comprimen los streams de contenido, cómo se guardan y empaquetan los objetos | Depende de lo suelto que estuviera el original | Aspecto de las páginas sin cambios |
| Reducción de resolución de imágenes | El número de píxeles, es decir, la resolución | Grande | Resolución reducida de forma permanente |
| Recodificación de imagen con pérdida | La representación en bytes del mapa de bits | Grande | Calidad de imagen reducida |
| Subsetting de fuentes | Las tablas de glifos embebidas | Moderada | Los glifos no usados dejan de ser editables |
| Linearización | El orden de los objetos | Casi nula | Compra en cambio el tiempo de carga de la primera página |
Las cuatro primeras filas reciben el nombre genérico de «compresión», pero solo la primera deja intacto el contenido. Es también la fila cuyo rendimiento es más fácil de juzgar mal: un escaneo cuyo tamaño son sobre todo muestras de imagen en bruto tiene poca redundancia que quitar, y las palancas que de verdad lo recortarían son la reducción de resolución y la recodificación con pérdida, a cambio de perder esa resolución y esa calidad para siempre.
PDF123 Compress solo acciona una de las cuatro
Comprimir un PDF (POST /api/v1/misc/compress-pdf) hace solo la primera fila. Ejecuta qpdf con la compresión de los streams sin comprimir (--compress-streams=y), una segunda pasada sobre los streams ya comprimidos con Flate (--recompress-flate) y el empaquetado de objetos en object-streams (--object-streams=generate).
No reduce la resolución de las imágenes, no recodifica los mapas de bits a una calidad JPEG inferior ni hace subsetting de fuentes. Las páginas deberían verse igual, y el ahorro viene de la recompresión Flate y del empaquetado en object-streams.
La condición de fallo merece la misma claridad. Cuando el tamaño de un archivo son sobre todo datos de imagen ya comprimidos como JPEG, Flate no tiene nada que exprimir, porque esos bytes de imagen quedan fuera de lo que tocan los tres interruptores anteriores. Por eso un paquete de escaneos puede volver solo unos puntos porcentuales más pequeño, mientras que un PDF con mucho texto de tamaño similar gana bastante más.
El camino inverso es Descomprimir PDF, que expande los streams para inspeccionarlos (--qdf, object streams desactivados) y tampoco cambia el aspecto de las páginas.
Cuándo la respuesta correcta es otro camino
| Lo que necesitas | El camino que usar |
|---|---|
| Aspecto idéntico, solo quitar la sobrecarga del empaquetado | Comprimir |
| Un paquete de escaneos realmente demasiado grande y pérdida de calidad aceptable | Reducción de resolución o recodificación con pérdida, no este Compress |
| Sigue siendo editable, pero el siguiente carácter no se escribirá | Otros ajustes de exportación o el archivo de origen, véase subsetting de fuentes |
| Que el navegador vea antes la primera página | La linearización resuelve el primer pintado, no el tamaño |
| El archivo no abre en absoluto | Reparar, un problema estructural y no de tamaño |
En esa última fila se esconde una trampa: Linearizar un PDF no es aquí una implementación aparte, es un alias de Compress. Ambos apuntan a la misma operación, el id canónico es misc/compress-pdf con linearize-pdf como alias, el portal siempre envía linearize=true y optimizeLevel=1 para esa herramienta, el servidor no lee ninguno de los dos campos y a qpdf nunca se le pasa --linearize. La operación que sí lineariza un archivo es Proteger, cuando cifra.
Así que si lo que quieres es el mismo aspecto en un archivo más pequeño, Comprimir es toda la respuesta. Si quieres reducción de imagen con pérdida o subsetting de fuentes, este camino es la palanca equivocada. El archivo vuelve directamente, sin necesidad de cuenta. Para ver dónde viven de verdad los objetos, los streams y la tabla de referencias cruzadas, continúa con Qué hay dentro de un PDF.