Por qué el peso de un PDF no se reparte entre sus páginas
La mitad de las páginas no pesa la mitad. Un PDF comparte fuentes e imágenes entre páginas, así que la única cifra fiable es la que sale al guardar el archivo.
Coge un PDF de 100 páginas que pesa 60 MB y pártelo por la mitad. Lo lógico sería acabar con dos archivos de unos 30 MB. Lo que sale puede ser 44 MB y 21 MB, y los dos juntos pesan más que el original del que partías.
Esto despista a casi todo el mundo, y es la razón de que dividir un PDF por tamaño sea un problema más peliagudo de lo que parece. Preguntar cuánto pesa la página 7 no tiene respuesta.
Un PDF no es un montón de páginas
El modelo mental que arrastramos es de papel: un documento son páginas, las páginas son hojas y las hojas se apilan. Un PDF no funciona así ni de lejos.
Dentro del archivo hay una bolsa de objetos numerados, y las páginas son solo algunos de ellos. El objeto de una página es minúsculo, casi todo referencias: usa la fuente 12, usa la imagen 47, aquí van las instrucciones de dibujo. Lo pesado vive una sola vez en la bolsa y cada página que lo necesita apunta a esa misma copia.
Una fuente incrustada se guarda una vez, la usen 2 páginas o 200. El logotipo del membrete de todas las páginas es una imagen referenciada noventa veces, no noventa imágenes. Con los perfiles de color, los datos ICC o los XObjects compartidos pasa igual.
Así que vuelve a la pregunta de cuánto pesa la página 7. ¿Le toca la fuente entera, o una centésima parte? No hay respuesta porque esos bytes no pertenecen a ninguna página.
Dos efectos que tiran en direcciones contrarias
Juntas, las páginas salen más baratas. Tres páginas que usan la misma fuente incrustada en un archivo la llevan una vez. Ponlas en tres archivos y tienes tres copias. Por eso partir engorda el total: los recursos compartidos se duplican en cada trozo que los necesita. En un informe con mucho texto y dos o tres familias tipográficas incrustadas, la suma de los trozos puede pesar bastante más que el original.
Una página suelta puede salir carísima. Una página con una foto de 12 MB se lleva los 12 MB al trozo que la contenga, mientras sus vecinas ocupan 40 KB cada una. De ahí que los trozos queden desiguales, con 60 páginas en uno y 2 en el siguiente: se están repartiendo bytes, no páginas.
La compresión llega al final
Hay una segunda capa. Al escribir el PDF, los objetos pequeños se agrupan en flujos de objetos y se comprimen juntos, y la tabla de referencias cruzadas se comprime con ellos. Lo bien que salga depende de qué haya en el paquete: cien objetos de página parecidos comprimen de maravilla en grupo, diez rinden proporcionalmente peor.
O sea que el peso de un conjunto de páginas ni siquiera está fijado hasta que decides qué más va a acompañarlas dentro del archivo. No hay fórmula. Hay escribir el archivo y mirar cuánto ha salido.
Por eso la herramienta guarda de verdad
Esa es la decisión de diseño detrás de la herramienta: no estima, construye un PDF real con un rango candidato de páginas, lo guarda y lee el número de bytes. La cifra de la tabla de resultados es esa medición, y los bytes que descargas son los mismos que se pesaron. No se vuelve a guardar después con otras opciones, porque medir con unos ajustes y entregar con otros da un número que no sirve para nada.
El problema es el coste. Guardar un documento no es gratis, y la versión ingenua de esto se pone fea enseguida.
Encontrar el corte sin congelar la pestaña
Lo evidente sería ir de una en una: prueba con 1 página, guarda, cabe; prueba con 2, guarda, cabe; prueba con 3… y para al pasarte. Para un trozo que acabe con m páginas son m guardados, y cada guardado serializa hasta m páginas. Aplícalo al documento entero y el coste en bytes movidos es cuadrático. En un PDF de 300 páginas eso son treinta segundos de pestaña bloqueada.
Lo que hace la herramienta es galopar y luego bisecar:
- Galope. Prueba con 1 página, luego 2, 4, 8, 16, doblando hasta que un candidato se pasa del límite. Ya sabes que el corte está entre el último tamaño que cupo y el primero que no, y has gastado del orden de log₂(m) guardados.
- Bisección. Búsqueda binaria dentro de ese intervalo para dar con el mayor número de páginas que todavía cabe. Otros log₂(m) guardados.
Unos 2·log₂(m) guardados por trozo en vez de m. Para un trozo de 64 páginas son una docena en lugar de sesenta y cuatro, y el total de bytes serializados en el documento baja de cuadrático a n·log m.
La bisección da por hecho que añadir páginas nunca reduce el tamaño. Es cierto salvo en casos patológicos, y aun así hay red: el trozo que descargas es el búfer que se midió, no una reconstrucción posterior, de modo que ni un documento raro puede colar un archivo por encima del límite.
La página que no cabe en ningún sitio
Si una página sola ya pesa más que el límite, no queda jugada. Las páginas no se subdividen. Esa página va en un trozo para ella sola y aparece marcada en la tabla antes de que descargues nada, con un aviso que dice qué número de página es.
Que te devuelvan un archivo por encima del tope sin avisar es lo que hace que mandes dos veces el mismo correo fallido, así que ese aviso es el detalle importante. Cuando te salga, el arreglo está más arriba: aligerar la página. Los escaneos suelen ser los culpables, y comprimir antes hace desaparecer el problema muchas veces.
Qué te llevas de aquí
Si necesitas trozos de un peso concreto, dividir por tamaño es lo tuyo, porque mide en vez de adivinar. Si lo que necesitas son trozos con un contenido concreto, la 1 a la 12 en un documento y la 13 a la 40 en otro, ese es otro trabajo y dividir por rango de páginas lo hace directamente.
Y no te extrañe que los trozos salgan descompensados ni que sumados pesen más de lo que tenías al empezar. Es el formato siendo sincero sobre cómo guarda las cosas.