Como o menor GIF possível , o menor possível em branco páginas PDF precisa ser trabalhado à mão, porque é tão pequena que os bits desnecessários-mas-inofensiva de metadados tornam-se uma parte significativa do tamanho do arquivo e compressão realmente torna as coisas maiores . Também requer atenção cuidadosa às regras na especificação do PDF sobre quais bits da estrutura do arquivo são e não são necessários. (Você sabia que os objetos da página devem conter um /Resources
dicionário, mesmo que esteja vazio, mas não precisam incluir um /Contents
fluxo?)
Se você não usar o objeto PDF 1.5 e fluxos de referência cruzada (que tem a vantagem de que o arquivo pode ser completamente imprimível em ASCII), acredito que o melhor que você pode fazer é 317 bytes. Se estiver copiando e colando, observe que precisa 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 deve haver 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, pelo preço de não ser mais ASCII imprimível: 294 bytes. (Para fins de legibilidade, sem mencionar a possibilidade de digitá-lo, o fluxo de refex abaixo foi hexdump, mas isso não é refletido em seu dicionário de stream. Para recuperar um PDF válido, você deve substituir o hexdump pelo bytes binários brutos correspondentes ou altere /Length 15
para /Length 30/Filter/ASCIIHexDecode
e aceite um arquivo com 328 bytes.)
%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
Também experimentei agrupar os objetos 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 de refex é
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 no comprimento dos dados reais do fluxo, o adicional /Index[1 4]
consome quase um byte da economia. Além disso, não está claro para mim se você tem permissão para 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 for necessário, você realmente salvará 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 americana ou 25,4 milímetros). Por exemplo, 595 842
para A4. Você pode incorporar isso em um script de shell que cospe um PDF em branco de qualquer tamanho de papel desejado; a única parte complicada seria garantir que o startxref
deslocamento permanecesse preciso, mesmo que o tamanho do objeto 3 fosse alterado.