Al igual que el GIF más pequeño posible , el PDF de página en blanco más pequeño posible debe elaborarse a mano, porque es tan pequeño que fragmentos de metadatos innecesarios pero inofensivos se convierten en una parte significativa del tamaño del archivo, y la compresión en realidad hace que las cosas sean más grandes . También requiere una atención cuidadosa a las reglas en la especificación de PDF sobre qué partes de la estructura del archivo son y no son necesarias. (¿Sabía que los objetos de página deben contener un /Resources
diccionario, incluso si está vacío, pero no están obligados a incluir una /Contents
secuencia?)
Si no utiliza el objeto PDF 1.5 y las secuencias de referencia cruzada (que tiene la ventaja de que el archivo puede ser ASCII completamente imprimible), creo que lo mejor que puede hacer es 317 bytes. Si copiar y pegar, tomar nota de que es necesario que haya un espacio al final de las cuatro entradas de la tabla de referencias cruzadas (entre las líneas 0 4
y trailer<<...
), y que no hay , no supone que hay un salto de línea final después de la %%EOF
.
%PDF-1.4
1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj
2 0 obj<</Type/Pages/Count 1/Kids[3 0 R]>>endobj
3 0 obj<</Type/Page/MediaBox[0 0 612 792]/Parent 2 0 R/Resources<<>>>>endobj
xref
0 4
0000000000 65535 f
0000000009 00000 n
0000000052 00000 n
0000000101 00000 n
trailer<</Size 4/Root 1 0 R>>
startxref
178
%%EOF
Reemplazar la tabla de referencia cruzada con una secuencia de referencia cruzada v1.5 diseñada manualmente hace que el archivo sea un poco más pequeño, al precio de que ya no se puede imprimir ASCII: 294 bytes. (En aras de la legibilidad, sin mencionar la posibilidad de escribirlo en absoluto, la secuencia xref a continuación se ha duplicado, pero esto no se refleja en su diccionario de secuencias. Para recuperar un PDF válido, debe reemplazar el hexdump con el correspondiente bytes binarios sin formato, o el cambio /Length 15
de /Length 30/Filter/ASCIIHexDecode
y aceptar un archivo que es de 328 bytes de longitud.)
%PDF-1.5
1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj
2 0 obj<</Type/Pages/Count 1/Kids[3 0 R]>>endobj
3 0 obj<</Type/Page/MediaBox[0 0 612 792]/Parent 2 0 R/Resources<<>>>>endobj
4 0 obj<</Type/XRef/Size 5/W[1 1 1]/Root 1 0 R/Length 15>>stream
0000ff01090001340001650001b200endstream endobj
startxref
178
%%EOF
También experimenté envolviendo objetos del 1 al 3 en una secuencia de objetos, pero esto agrega más sobrecarga de la que ahorra, incluso cuando la secuencia está comprimida.
Una posible formulación alternativa de la corriente xref es
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
Lamentablemente, a pesar de los ahorros sustanciales en la longitud de los datos de transmisión reales, el adicional /Index[1 4]
consume todos menos un byte de los ahorros. Además, no me queda claro si puede dejar el objeto 0 completamente fuera del archivo. (Tampoco me queda claro si el objeto 0 debe tener el número de generación -1. Si eso no es necesario, en realidad guarda más bytes con
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.)
Para cambiar el tamaño del papel, reemplácelo 612 792
con el ancho y la altura apropiados, expresados en puntos PostScript (72 puntos PostScript = 1 pulgada de EE. UU. O 25,4 milímetros). Por ejemplo, 595 842
para A4. Puede incrustar esto en un script de shell que escupe un PDF en blanco del tamaño de papel deseado; La única parte difícil sería asegurarse de que el startxref
desplazamiento permaneciera exacto incluso si el tamaño del objeto 3 cambiara.