Як і найменший можливий GIF , найменший PDF-файл із порожньою сторінкою потрібно опрацювати вручну, оскільки він настільки малий, що непотрібні, але нешкідливі біти метаданих стають значною частиною розміру файлу, а стиснення насправді робить речі більші . Він також вимагає уважної уваги до правил у специфікації PDF щодо того, які біти структури файлів є, а які не потрібні. (Чи знали ви, що об’єкти сторінки повинні містити /Resources
словник, навіть якщо він порожній, але не потрібно включати /Contents
потік?)
Якщо ви не використовуєте об'єктні та перехресні посилання PDF 1.5 (що має перевагу в тому, що файл може бути повністю надрукований ASCII), я вважаю, що найкраще ви можете зробити 317 байт. Якщо копіюєте та вставляєте, врахуйте, що для всіх чотирьох записів таблиці перехресних посилань (рядків між 0 4
та trailer<<...
) не повинно бути пробілу, а після завершення не повинно бути остаточного нового рядка %%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
Заміна таблиці перехресних посилань на створений вручну потік перехресних посилань v1.5 робить файл трохи меншим, ціною його більше не можна друкувати ASCII: 294 байти. (Для читабельності, не кажучи вже про можливість вводити його взагалі, потік xref, наведений нижче, був генерований, але це не відображено в його словнику потоків. Щоб відновити дійсний PDF-файл, потрібно або замінити hexdump на відповідні необроблені двійкові байти, або змінити , /Length 15
щоб /Length 30/Filter/ASCIIHexDecode
і прийняти файл , який має довжину 328 байт.)
%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
Я також експериментував із загортанням об'єктів від 1 до 3 в поток об'єктів, але це додає більше витрат на голову, ніж економить, навіть коли потік стискається.
Можливою альтернативною формулюванням потоку xref є
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
На жаль, незважаючи на значну економію тривалості фактичних даних потоку, додаткові /Index[1 4]
з'їдають всі, крім одного байту, заощадження. Також мені незрозуміло, чи вам дозволяється повністю залишити об'єкт 0 із файлу. (Також мені незрозуміло, чи повинен об'єкт 0 мати номер покоління -1. Якщо цього не потрібно, ви фактично зберігаєте більше байтів
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.)
Щоб змінити розмір паперу, замініть 612 792
відповідну ширину та висоту, виражену в точках PostScript (72 пункти PostScript = 1 дюйм США або 25,4 міліметра). Наприклад, 595 842
для формату A4. Ви можете вбудувати це в сценарій оболонки, який випилює порожній PDF будь-якого розміру паперу; Єдина хитра частина - переконатися, що startxref
зміщення залишається точним, навіть якщо розмір об'єкта 3 змінився.