Una pasada de compresión de PDF sin pérdida reescribe la estructura interna del archivo en lugar de recodificar las imágenes que contiene. Medimos lo que eso ahorra realmente en ocho PDF de prueba. Tres de ellos salieron más grandes en al menos un modo, y el peor aumento fue del 20.8 por ciento.
El ahorro depende de cuán suelta estuviera la entrada. Los flujos de texto sin comprimir se redujeron entre un 84 y un 90 por ciento, mientras que un archivo cuyos flujos ya estaban comprimidos con Flate se redujo un 31.6 por ciento en modo estándar y creció un 3.0 por ciento en modo máximo. Una segunda pasada no cambió nada en ninguna muestra, y dos archivos con el mismo contenido pero estructura distinta produjeron una salida idéntica byte a byte. Nada de esto significa que el motor sea defectuoso; significa que una afirmación de tamaño necesita una medición detrás. El método completo, la tabla y los límites de la prueba están más abajo.
Toda herramienta de PDF tiene un botón Comprimir, y casi todas informan de éxito. Esa palabra cubre al menos dos operaciones muy distintas, y una de ellas puede devolverte un archivo más grande. Queríamos números en lugar de una promesa, así que creamos ocho PDF con estructuras internas deliberadamente diferentes y pasamos cada uno por qpdf 11.7.0 usando los mismos argumentos que pasa nuestra propia herramienta.
Comprimir PDF
La misma pasada de qpdf descrita aquí, compilada a WebAssembly y ejecutada dentro de la pestaña. Elige el nivel y luego lee tú mismo los tamaños antes y después.
Qué hace realmente un botón de "comprimir PDF"
Lo primero que merece la pena saber es que esto normalmente no es recompresión de imágenes. Es una reescritura estructural. Un PDF guarda sus páginas como una colección de objetos y flujos, y la pasada los desempaqueta, elimina la duplicación, comprime los flujos que se almacenaron en bruto y escribe un archivo nuevo.
qpdf, el motor dentro de nuestra herramienta, hace eso con esta llamada en modo estándar:
--object-streams=generate --compress-streams=y --recompress-flate --compression-level=6y esta otra en modo máximo, que añade un nivel superior y linealización para una visualización web rápida:
--object-streams=generate --compress-streams=y --recompress-flate --compression-level=9 --linearizeFíjate en lo que no está en ninguna de las dos llamadas: nada que toque las imágenes incrustadas. Una pasada estructural no decodifica un JPEG que ya está dentro de un PDF, así que no puede encoger de forma significativa un documento escaneado o cargado de fotos. Lo que sí puede hacer es eliminar la ineficiencia que se acumuló mientras se construía el archivo. Por eso el ahorro depende de la entrada y no de cuánto se esfuerce la herramienta.
Cómo se realizó la medición
Se generaron ocho muestras para aislar una propiedad estructural cada una: un archivo mínimo de una página, un archivo de tres páginas, el mismo documento de veinte páginas con flujos comprimidos y sin comprimir, un archivo de cien páginas con muchos objetos, un archivo de una página rellenado con un comentario basura, un archivo con un JPEG incrustado y un archivo con un pequeño paquete XMP sin comprimir. Cada archivo se procesó después con los argumentos anteriores, dos veces en el caso del modo estándar, y se registraron la cuenta de bytes y el hash SHA-256 cada vez.
- Genera las muestras con un script, no a mano. Eso hace que cada una sea reproducible y evita que la prueba dependa de los documentos que resultara que tuvieras a mano.
- Usa los argumentos reales de la herramienta. Se llama al motor con exactamente los mismos indicadores que pasa la herramienta del navegador, así que los números describen el producto y no un experimento de aspecto parecido.
- Registra bytes y hashes, no solo un porcentaje. Un hash responde a una segunda pregunta que el tamaño no puede: si dos entradas construidas de forma distinta acaban siendo el mismo archivo.
- Ejecuta todo una segunda vez. Repetir la operación comprueba si converge, lo que importa si una interfaz te invita a pulsar el botón otra vez.
Los números
El modo estándar es nivel 6 sin linealización. El máximo es nivel 9 con linealización. Los porcentajes negativos son archivos más pequeños.
| Muestra | Entrada (B) | Estándar (B) | Cambiar | Máximo (B) | Cambiar |
|---|---|---|---|---|---|
| 01 mínimo, 1 página | 3,392 | 872 | -74.3% | 1,637 | -51.7% |
| 02 mínimo, 3 páginas | 9,520 | 1,475 | -84.5% | 2,513 | -73.6% |
| 03 texto sin comprimir, 20 páginas | 62,145 | 6,590 | -89.4% | 9,916 | -84.0% |
| 04 texto comprimido, 20 páginas | 9,629 | 6,590 | -31.6% | 9,916 | +3.0% |
| 05 muchos objetos, 100 páginas | 311,281 | 30,964 | -90.1% | 45,110 | -85.5% |
| 06 estructura suelta, 1 página | 7,489 | 872 | -88.4% | 1,637 | -78.1% |
| 07 imagen JPEG incrustada | 67,974 | 68,124 | +0.2% | 68,863 | +1.3% |
| 08 XMP sin comprimir | 4,151 | 4,235 | +2.0% | 5,013 | +20.8% |
Cuatro cosas que dicen los números
La ganancia viene de que la entrada esté suelta, no de que la herramienta sea lista
Los archivos cuyos flujos de texto estaban almacenados sin comprimir se redujeron entre un 84 y un 90 por ciento. Un archivo cuyos flujos ya estaban comprimidos con Flate se redujo un 31.6 por ciento en modo estándar y luego creció un 3.0 por ciento en modo máximo, porque el nivel 9 más la linealización añadieron una estructura que el archivo no necesitaba. Más esfuerzo no es lo mismo que un archivo más pequeño, y el límite es la estructura de la entrada, no el esfuerzo aplicado a ella.
Tres de las ocho muestras crecieron
El peor caso fue un aumento del 20.8 por ciento en un archivo que llevaba un pequeño paquete XMP sin comprimir, pasado por el modo máximo. La muestra con un JPEG incrustado creció en ambos modos, porque no había nada estructural que ganar y la reescritura en sí misma cuesta bytes. Esta es la parte que esconde un mensaje de éxito: un compresor que siempre informa de éxito no está midiendo nada, y en estas entradas la salida honesta es un archivo ligeramente más grande.
La operación es idempotente sobre su propia salida
Cada muestra se pasó una segunda vez por la ruta estándar, y cada cambio de la segunda pasada fue del 0.0 por ciento. Una vez que un archivo se ha reescrito, reescribirlo de nuevo no encuentra nada. Si una herramienta parece encontrar ahorros nuevos cada vez que pulsas el botón, eso es una razón para mirar qué está haciendo en realidad y no una señal de minuciosidad.
La reescritura normaliza, no se limita a recortar
Las muestras 01 y 06 son el mismo documento de una página, salvo que la 06 lleva cuatro kilobytes de comentario basura. Tras la reescritura producen el mismo hash SHA-256. Las muestras 03 y 04 son el mismo documento de veinte páginas con flujos comprimidos y sin comprimir, y convergen de la misma forma. El motor está reconstruyendo el archivo en una forma canónica en lugar de recortar lo que encuentre, y por eso también una segunda pasada no tiene nada que hacer.
Cómo saber si un compresor midió algo
Dos comprobaciones de aproximadamente un minuto cada una y que funcionan con cualquier herramienta.
- Pide el número. Un mensaje que dice Comprimido sin una cuenta de bytes antes y después no te ha dicho nada. Los casos que merecen atención son los archivos pequeños y los que ya están bien hechos, donde la respuesta honesta suele ser que creció.
- Prueba con un archivo que ya esté ajustado. Una exportación de una suite ofimática moderna normalmente ya está comprimida. Si una herramienta todavía afirma un gran ahorro en ella, o está recodificando tus imágenes, lo que es una decisión de calidad y no algo sin pérdida, o está adivinando.
Ambas comprobaciones apuntan a la misma idea. Un optimizador estructural no tiene un tamaño objetivo al que aspirar, y por eso nuestra propia herramienta no tiene ningún campo para uno y por eso la descripción honesta de lo que puede hacer depende del documento que tenga delante.
Dónde tiene límites esta prueba
Los números anteriores son reales y son limitados. Ser claro sobre sus lagunas es precisamente el motivo de publicarlos.
- Las muestras se generan, no se recopilan. Aíslan propiedades estructurales a propósito, así que no son una muestra aleatoria de los PDF que la gente tiene de verdad.
- Ocho es un conjunto pequeño. Lee los porcentajes como prueba de que existe una horquilla, no como una media para todos los PDF.
- Las imágenes están representadas por una sola muestra. Un único JPEG incrustado representa toda una clase de documentos. No se probaron anidamientos más profundos de imágenes, fuentes y campos de formulario.
- El motor nunca recodifica imágenes aquí. Eso es una propiedad de la pasada estructural de qpdf, no algo que este conjunto de datos demuestre sobre otros compresores.
- Las versiones importan. Estos resultados pertenecen a qpdf 11.7.0. Si una versión posterior cambia su optimización, los números cambian con ella y hay que volver a ejecutar el método.
Preguntas frecuentes
Si quieres el panorama más amplio de lo que una herramienta del navegador puede y no puede hacer con un documento, la guía sobre comprimir un PDF sin subirlo cubre el motor y la ruta del archivo, y la cuestión de los tamaños objetivo explica por qué un optimizador sin pérdida no tiene un campo para uno.