Assim como o menor GIF possível , o menor PDF possível em uma página em branco precisa ser trabalhado à mão, porque é tão pequeno que bits de metadados desnecessários, mas inofensivos, se tornam uma parte significativa do tamanho do arquivo, e a compactação realmente torna as coisas maiores . Ele também requer cuidadosa atenção às regras da especificação do PDF sobre quais bits da estrutura do arquivo são ou não necessários. (Você sabia que os objetos de página devem conter um dicionário /Resources , mesmo se estiver vazio, mas não são necessários para incluir um fluxo /Contents ?)
Se você não usa o objeto PDF 1.5 e fluxos de referência cruzada (que tem a vantagem de que o arquivo pode ser completamente imprimível ASCII) eu acredito que o melhor que você pode fazer é 317 bytes. Se estiver copiando e colando, observe que é preciso haver um espaço à direita em todas as quatro entradas da tabela de referência cruzada (as linhas entre 0 4 e trailer<<... ) e que não há não deveria ser uma nova linha final após o %%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
Substituir a tabela de referência cruzada por um fluxo de referência cruzada v1.5 criado manualmente torna o arquivo um pouco menor, com o preço de não mais ser ASCII: 294 bytes imprimíveis. (Para facilitar a leitura, para não mencionar a possibilidade de digitá-lo, o fluxo de xref abaixo foi hexdumped, mas isso não é não refletido em seu dicionário de fluxo. Para recuperar um PDF válido, deve substituir o hexdump pelos bytes binários brutos correspondentes ou alterar /Length 15 para /Length 30/Filter/ASCIIHexDecode e aceitar um arquivo com 328 bytes de comprimento.
%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
Eu também experimentei agrupar objetos de 1 a 3 em um fluxo de objetos, mas isso adiciona mais sobrecarga do que economiza, mesmo quando o fluxo é compactado.
Uma possível formulação alternativa do fluxo xref é
4 0 obj<</Type/XRef/Size 4/W[0 1 0]/Index[1 4]/Root 1 0 R/Length 4>>stream
091365b2endstream endobj
Infelizmente, apesar das economias substanciais na duração dos dados reais do stream, o /Index[1 4] adicional consome todos menos um byte da economia. Além disso, não está claro se você está autorizado a deixar o objeto 0 completamente fora do arquivo. (Também não está claro para mim se o objeto 0 deve ter o número de geração -1. Se isso não é necessário, você realmente salva mais bytes com
4 0 obj<</Type/XRef/Size 5/W[1 1 0]/Root 1 0 R/Length 10>>stream
000001090134016501b2endstream endobj
.
Para alterar o tamanho do papel, substitua 612 792 pela largura e altura apropriadas, expressas em pontos PostScript (72 pontos PostScript = 1 polegada norte-americana ou 25,4 milímetros). Por exemplo, 595 842 para A4. Você poderia inserir isso em um script de shell que cosesse um PDF em branco de qualquer tamanho de papel desejado; a única parte complicada seria certificar-se de que o startxref offset permanecesse exato, mesmo se o tamanho do objeto 3 fosse alterado.