Seperti GIF terkecil yang mungkin, PDF halaman kosong terkecil yang mungkin perlu dikerjakan dengan tangan, karena sangat kecil sehingga bit metadata yang tidak perlu namun tidak berbahaya menjadi bagian penting dari ukuran file, dan kompresi sebenarnya membuat segalanya lebih besar . Ini juga membutuhkan perhatian cermat terhadap aturan dalam spesifikasi PDF tentang bit apa dari struktur file yang diperlukan dan yang tidak diperlukan. (Tahukah Anda bahwa objek halaman harus berisi /Resources
kamus, meskipun kamus itu kosong, tetapi tidak diharuskan menyertakan /Contents
aliran?)
Jika Anda tidak menggunakan objek PDF 1.5 dan aliran referensi silang (yang memiliki keuntungan bahwa file tersebut dapat sepenuhnya dicetak ASCII) Saya percaya yang terbaik yang dapat Anda lakukan adalah 317 byte. Jika copy dan paste, perhatikan bahwa perlu ada sebuah ruang tambahan pada semua empat dari entri tabel referensi silang (garis antara 0 4
dan trailer<<...
), dan bahwa ada tidak seharusnya menjadi baris baru akhir setelah %%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
Mengganti tabel referensi silang dengan stream referensi silang v1.5 yang dibuat secara manual memang membuat file sedikit lebih kecil, dengan harga yang tidak lagi dapat dicetak ASCII: 294 bytes. (Demi keterbacaan, belum lagi bisa mengetik sama sekali, aliran xref di bawah ini telah hexdumped, tetapi ini tidak tercermin dalam kamus alirannya. Untuk memulihkan PDF yang valid Anda harus mengganti hexdump dengan sesuai byte biner mentah, atau mengubah /Length 15
ke /Length 30/Filter/ASCIIHexDecode
dan menerima file yang 328 byte panjang.)
%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
Saya juga bereksperimen dengan membungkus objek 1 hingga 3 ke dalam aliran objek, tetapi ini menambahkan kembali lebih banyak overhead daripada menghemat, bahkan ketika aliran dikompresi.
Formulasi alternatif yang mungkin dari aliran xref adalah
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
Sayangnya, terlepas dari penghematan besar dalam panjang data stream aktual, tambahan /Index[1 4]
memakan semua kecuali satu byte penghematan. Juga, tidak jelas bagi saya apakah Anda diizinkan untuk meninggalkan objek 0 sepenuhnya dari file. (Ini juga tidak jelas bagi saya apakah objek 0 harus memiliki nomor generasi -1. Jika itu tidak diperlukan, Anda sebenarnya menyimpan lebih banyak byte
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.)
Untuk mengubah ukuran kertas, ganti 612 792
dengan lebar dan tinggi yang sesuai, dinyatakan dalam poin PostScript (72 poin PostScript = 1 inci AS atau 25,4 milimeter). Misalnya, 595 842
untuk A4. Anda bisa menanamkan ini dalam skrip shell yang mengeluarkan PDF kosong dari ukuran kertas apa pun yang diinginkan; satu-satunya bagian yang sulit adalah memastikan bahwa startxref
offset tetap akurat bahkan jika ukuran objek 3 berubah.