Come la GIF più piccola possibile , il PDF a pagina vuota più piccolo possibile deve essere elaborato a mano, perché è così piccolo che i bit di metadati non necessari ma innocui diventano una parte significativa della dimensione del file e la compressione rende le cose più grandi . Richiede inoltre un'attenta attenzione alle regole delle specifiche PDF su quali bit della struttura dei file sono e non sono richiesti. (Sapevi che gli oggetti della pagina devono contenere un /Resources
dizionario, anche se è vuoto, ma non è necessario includere uno /Contents
stream?)
Se non usi gli oggetti PDF 1.5 e i flussi di riferimenti incrociati (il che ha il vantaggio che il file può essere completamente ASCII stampabile) credo che il meglio che puoi fare sia 317 byte. Se copiando e incollando, prendere nota che ci deve essere uno spazio finale su tutte e quattro le voci della tabella di riferimento incrociato (le linee tra 0 4
e trailer<<...
), e che è non doveva essere una nuova riga finale dopo 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
La sostituzione della tabella dei riferimenti incrociati con un flusso di riferimenti incrociati v1.5 creato manualmente rende il file leggermente più piccolo, al prezzo del suo ASCII non più stampabile: 294 byte. (Per motivi di leggibilità, per non parlare della possibilità di digitarlo, il flusso di xrif di seguito è stato scaricato in esadecimale, ma questo non si riflette nel suo dizionario di flusso. Per recuperare un PDF valido è necessario sostituire il hexdump con il corrispondente byte binari prime o cambiamento /Length 15
di /Length 30/Filter/ASCIIHexDecode
e accettare un file che è di 328 byte.)
%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
Ho anche sperimentato il wrapping di oggetti da 1 a 3 in un flusso di oggetti, ma ciò aggiunge più sovraccarico di quanto risparmi, anche quando il flusso è compresso.
Una possibile formulazione alternativa del flusso xrif è
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
Purtroppo, nonostante i sostanziali risparmi nella lunghezza dei dati di flusso effettivi, l'aggiunta /Index[1 4]
consuma tutti i risparmi tranne uno. Inoltre, non mi è chiaro se ti è permesso lasciare l'oggetto 0 completamente fuori dal file. (Non mi è nemmeno chiaro se l'oggetto 0 debba avere il numero di generazione -1. Se ciò non è necessario, in realtà si salvano più byte con
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.)
Per modificare il formato della carta, sostituire 612 792
con la larghezza e l'altezza appropriate, espresse in punti PostScript (72 punti PostScript = 1 pollice USA o 25,4 millimetri). Ad esempio, 595 842
per A4. Potresti incorporarlo in uno script di shell che sputa un PDF vuoto di qualsiasi dimensione del foglio sia desiderato; l'unica parte difficile sarebbe assicurarsi che l' startxref
offset rimanesse accurato anche se le dimensioni dell'oggetto 3 fossero cambiate.