Podobnie jak najmniejszy możliwy GIF , należy ręcznie opracować najmniejszy możliwy pusty plik PDF, ponieważ jest tak mały, że niepotrzebne, ale nieszkodliwe fragmenty metadanych stają się znaczną częścią rozmiaru pliku, a kompresja faktycznie powiększa . Wymaga to również starannego zwrócenia uwagi na reguły w specyfikacji PDF dotyczące tego, jakie bity struktury pliku są i nie są wymagane. (Czy wiesz, że obiekty strony muszą zawierać /Resources
słownik, nawet jeśli jest pusty, ale nie muszą zawierać /Contents
strumienia?)
Jeśli nie korzystasz ze strumieni obiektów PDF i strumieni odsyłaczy (co ma tę zaletę, że plik można w całości wydrukować w formacie ASCII), uważam, że najlepiej jest zrobić 317 bajtów. W przypadku kopiowania i wklejania, zwróć uwagę, że nie musi być spacją na wszystkich czterech wpisów tabeli odsyłaczy (granice pomiędzy 0 4
i trailer<<...
), i że nie jest nie ma być końcowy znak nowej linii po %%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
Zastąpienie tabeli odsyłaczy ręcznie spreparowanym strumieniem odsyłaczy w wersji 1.5 sprawia, że plik jest nieco mniejszy, a cena nie jest już możliwa do wydrukowania w ASCII: 294 bajtów. (Ze względu na czytelność, nie mówiąc już o możliwości wpisania go, poniższy strumień odnośników został zrzucony heksadecymalnie, ale nie znajduje to odzwierciedlenia w słowniku strumieni. Aby odzyskać prawidłowy plik PDF, należy albo zastąpić zrzut heksowy odpowiadająca surowych bajtów binarnych, lub zmienić /Length 15
na /Length 30/Filter/ASCIIHexDecode
i zaakceptować plik o długości 328 bajtów).
%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
Eksperymentowałem również z zawijaniem obiektów od 1 do 3 w strumień obiektów, ale to dodaje więcej narzutu niż oszczędza, nawet gdy strumień jest skompresowany.
Możliwe alternatywne sformułowanie strumienia odnośnika zewnętrznego to
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
Niestety, pomimo znacznych oszczędności w długości rzeczywistych danych strumienia, dodatkowe /Index[1 4]
zjadają wszystkie oprócz jednego bajta oszczędności. Ponadto nie jest dla mnie jasne, czy wolno pozostawić obiekt 0 całkowicie poza plikiem. (Nie jest też dla mnie jasne, czy obiekt 0 musi mieć numer generacji -1. Jeśli nie jest to wymagane, faktycznie zapisujesz więcej bajtów za pomocą
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.)
Aby zmienić rozmiar papieru, zamień 612 792
na odpowiednią szerokość i wysokość, wyrażoną w punktach PostScript (72 punkty PostScript = 1 cal amerykański lub 25,4 milimetra). Na przykład 595 842
dla A4. Możesz to osadzić w skrypcie powłoki, który wyrzuca pusty plik PDF o dowolnym rozmiarze papieru; jedyną trudną częścią byłoby upewnienie się, że startxref
przesunięcie pozostaje dokładne, nawet jeśli zmieni się rozmiar obiektu 3.