Tamanho máximo de PDF no browser

Existe um tamanho máximo de PDF no browser?

Não, no sentido de um número escrito numa especificação. Nenhum browser define um tamanho máximo de PDF, porque o browser não sabe o que é um PDF: sabe o que é um ficheiro, um bloco de bytes e uma tela de desenho. O tecto aparece quando uma dessas três coisas rebenta.

Isso muda a pergunta útil. Em vez de "que tamanho aguenta", a pergunta a fazer é "qual dos limites vou tocar primeiro", e a resposta depende do que você vai fazer com o ficheiro. Ler e reorganizar páginas custa memória proporcional ao ficheiro. Rasterizar custa memória proporcional à área das páginas vezes o número de páginas, e é sempre muito mais caro.

Que limites duros existem, com números?

O limite de área do canvas é de área, não de lado: no Safari, 4097 por 4096 falha, mas 5120 por 3072 passa, e os dois são maiores do que 4096 num dos lados. Quando o limite é excedido, o desenho não dá erro barulhento nenhum: o contexto vem vazio ou transparente, e o que aparece é uma página em branco.

Quanta memória custa desenhar uma página?

Um canvas guarda quatro bytes por píxel: vermelho, verde, azul e transparência. A conta é directa, e é o número que decide tudo o que vem a seguir.

Um PDF usa 72 pontos por polegada como unidade base, por isso a escala de desenho converte-se directamente em resolução. Uma folha A4 mede 595,276 por 841,890 pontos. Nos três níveis da nossa compressão dá isto:

A última coluna divide o orçamento de 384 MB do Safari em iOS pelo custo de uma página. Dá a ordem de grandeza, não uma garantia: o Safari não liberta um canvas no instante em que deixa de ser referenciado, guarda-o durante algum tempo, por isso o número real de páginas antes de falhar é mais baixo do que a divisão sugere.

Repare no que a tabela diz sobre o formato da página, e não só sobre o número de páginas. Um cartaz A0 (841 por 1189 mm) desenhado no nível médio dá 18 077 306 píxeis, acima dos 16 777 216 que o Safari aceita: essa página sai em branco. No nível forte dá 9 720 908 e passa. No Chrome, o limite de 268 435 456 píxeis só é atingido por uma página quadrada com quase três metros de lado.

O que muda entre 32 e 64 bits?

Muda o espaço de endereçamento, e com ele o tecto de um único bloco contíguo de bytes. Num processo de 32 bits, o comprimento de um bloco é guardado num inteiro com sinal de 32 bits, e por isso nenhum bloco pode passar de 2 147 483 647 bytes. É um limite duro que não depende da memória instalada na máquina: pode ter 32 GB de RAM e continuar a bater nele.

Num processo de 64 bits esse tecto desaparece, e o que passa a mandar é o alocador do browser e a memória livre. No Chrome, o alocador não costuma entregar mais do que cerca de 2 GB para um único bloco, mesmo em 64 bits.

Onde é que ainda encontra 32 bits em 2026: instalações antigas de Windows e telemóveis Android com processador de 32 bits. Se o seu browser é de 32 bits e o PDF passa de 2 GB, ele nem chega a ser lido.

O que muda num telemóvel?

Três coisas, todas para pior.

• Menos memória por aba. Um telemóvel tem menos RAM e o sistema mata separadores com muito mais facilidade do que um computador. No iPhone, a página recarrega sozinha e você perde o trabalho.
• O orçamento de canvas do Safari em iOS, que são 384 MB desde o iOS 15 e 224 MB antes disso. É um limite que não existe em nenhum browser de secretária.
• Processadores mais lentos. A parte de desenhar e codificar em JPEG corre no fio principal, por isso o separador fica sem responder durante a operação. Num telemóvel, isso dura mais tempo e parece uma avaria.

A partir de que ponto o BestPDFInTheWorld se engasga?

Vamos por partes, e a primeira coisa a dizer é o que não sabemos: nunca medimos um tecto próprio com ficheiros de teste, por isso não há aqui um número do género "acima de X MB falha". O que há é o que se pode afirmar com certeza sobre a implementação.

• No plano gratuito, o corte é nosso e é aos 10 485 760 bytes, ou seja 10 MB, verificado por ficheiro antes de a compressão arrancar. Acima disso a operação nem começa.
• Com subscrição activa não verificamos tamanho nenhum. A verificação é saltada por inteiro e o tecto passa a ser o browser. É uma decisão deliberada, mas quer dizer que um assinante pode escolher um ficheiro que o browser não aguenta e ver a aba morrer sem aviso prévio da nossa parte.
• Muitas das trinta e três ferramentas não desenham nada. Juntar, dividir, rodar, apagar páginas, imagens para PDF, numerar, marca de água e proteger só manipulam a estrutura do documento. O custo é da ordem de alguns múltiplos do tamanho do ficheiro, e são estas que aguentam ficheiros maiores.
• Comprimir e PDF para imagem rasterizam, e por isso são as que falham primeiro. O custo cresce com a área das páginas vezes o número de páginas, segundo a tabela acima.
• PDF para Word não rasteriza, mas percorre o documento inteiro para extrair o texto, e guarda o resultado em memória até ao fim.
• A leitura e a descodificação do PDF correm num Web Worker, com memória própria e fora do fio principal. O desenho no canvas e a codificação em JPEG correm no fio principal, e é por isso que a página deixa de responder durante uma compressão longa.
• Não há barra de progresso por página, nem botão de cancelar. Uma operação longa é indistinguível de uma operação encravada, e isso é um defeito nosso.

Como trabalhar com um PDF grande sem rebentar a aba?

1. Divida antes de fazer o resto. Dividir não rasteriza, e passar de um ficheiro de 400 páginas para oito de 50 muda o problema de sítio.
2. Apague as páginas que não interessam antes de comprimir. Menos páginas é menos canvas.
3. Escolha o nível forte em documentos longos. Custa 2 428 740 bytes por página A4 em vez de 8 022 576, ou seja um terço.
4. Faça-o num computador, não no telemóvel, quando o documento é longo. O orçamento de canvas do iOS é o limite mais apertado de todos.
5. Feche os outros separadores. A memória é do processo, e um separador com um vídeo a tocar tira-lha.
6. Guarde sempre o original. Se a aba morrer a meio, não há recuperação: nada foi guardado em lado nenhum, porque não há servidor.

Fontes

• MDN, elemento canvas
• Chromium, dimensão máxima do canvas (issue 339725)
• WebKit, limite de memória total de canvas (bug 195325)
• PQINA, Total canvas memory use exceeds the maximum limit
• Mozilla, ArrayBuffer acima de 2 GB em processos de 64 bits