Как наименьшее возможное 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 байта. (Для удобства чтения, не говоря уже о том, что он вообще может быть напечатан, приведенный ниже поток внешних ссылок был шестнадцатеричным, но это не отражено в словаре потоков. Чтобы восстановить действительный PDF-файл, необходимо либо заменить шестнадцатеричный код на соответствующие необработанные двоичные байты, или изменения /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 в поток объектов, но это добавляет больше накладных расходов, чем экономит, даже когда поток сжат.
Возможной альтернативной формулировкой потока внешних ссылок является
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 изменился.