Como a Edição de PDF no Browser Funciona e Por Que a Privacidade Importa

Cada vez que carrega um documento para uma ferramenta PDF baseada na nuvem, esse documento fica alojado em servidores que não controla, processado por software que não pode inspecionar, armazenado por uma empresa com as suas próprias políticas de retenção e segurança de dados. Por algum tempo, a infraestrutura de terceiros tem nas mãos os seus contratos, declarações de impostos, registos médicos ou documentos empresariais confidenciais.

O LuraPDF funciona de forma diferente. Tudo acontece no separador do seu browser, no seu hardware, com a gestão de memória do seu sistema operativo. Este artigo explica a arquitetura técnica que torna isto possível e os compromissos de engenharia envolvidos.

O Browser como Plataforma de Processamento de Documentos

Os browsers modernos já não são apenas renderizadores de HTML. São ambientes de execução de aplicações completos, com:

• Motor JavaScript (V8 no Chrome, SpiderMonkey no Firefox): executa código a velocidade quase nativa
• WebAssembly (WASM): executa código C/C++ compilado a velocidade quase nativa num ambiente isolado (sandbox)
• Canvas API: permite a manipulação de imagens ao nível do pixel
• File System Access API: permite ler ficheiros locais sem fazer upload
• Web Workers: executa computação em threads de fundo sem congelar a interface
• ArrayBuffer / Blob: gere dados binários brutos (como bytes de PDF) em memória

Estas capacidades em conjunto permitem uma pipeline de processamento de documentos completa que, há cinco anos, teria exigido um servidor de backend.

As Três Bibliotecas Principais

O LuraPDF é construído sobre três bibliotecas open-source fundamentais:

pdf-lib

pdf-lib é uma biblioteca TypeScript para criar e modificar documentos PDF em qualquer ambiente JavaScript. Implementa uma parte substancial da especificação PDF (ISO 32000), incluindo:

• Criação, modificação e eliminação de páginas
• Incorporação de tipos de letra (tanto os 14 tipos de letra padrão como tipos TTF/OTF personalizados)
• Incorporação de imagens (JPEG, PNG)
• Colocação de anotações de texto
• Criação e manipulação de campos de formulário
• Metadados do documento (título, autor, data de criação, etc.)
• Proteção do documento com palavra-passe
• Gestão da tabela de referências cruzadas

Quando o LuraPDF une PDFs, utiliza a pdf-lib para ler a árvore de páginas de cada documento, normalizar recursos partilhados e montar um novo PDF. Quando comprime, recodifica os objetos de imagem com fatores de qualidade mais baixos. Quando protege um ficheiro com palavra-passe, deriva uma chave a partir da sua palavra-passe e escreve um documento encriptado usando o PDF Standard Security Handler, que todos os leitores compreendem.

A pdf-lib opera inteiramente sobre objetos ArrayBuffer — dados binários brutos na memória do browser. Não são efetuadas chamadas de rede.

pdfjs-dist

PDF.js é o motor de renderização de PDF da Mozilla, distribuído como pdfjs-dist no npm. É o motor que alimenta o visualizador de PDF integrado do Firefox, testado em milhões de PDFs reais.

O LuraPDF utiliza o pdfjs-dist para:

• Renderização de páginas: Converter páginas PDF em Canvas ImageData para visualização
• Extração de texto: Ler os fluxos de conteúdo de texto das páginas PDF
• Metadados de página: Obter dimensões de página, valores de rotação e tipo de conteúdo

Quando vê o seu PDF renderizado na interface do LuraPDF — a pré-visualização visual das páginas — é o pdfjs-dist a renderizar cada página num elemento HTML Canvas.

Tesseract.js

Tesseract.js é a versão compilada em WebAssembly do Tesseract OCR. O Tesseract é um motor OCR open-source originalmente desenvolvido pelos HP Labs (1985) e atualmente mantido pela Google. Utiliza um modelo de rede neuronal LSTM (Long Short-Term Memory) para reconhecimento de caracteres.

Executar o Tesseract via WebAssembly no browser significa:

• O binário WASM de 22 MB é carregado uma vez e guardado em cache pelo browser
• O processamento OCR é executado na CPU via WebAssembly, não na GPU
• O processamento é mais lento do que o OCR na nuvem (que utiliza clusters de GPU), mas produz resultados com a mesma qualidade
• O conteúdo do seu documento nunca sai do seu dispositivo

Para uma digitalização de 20 páginas: o OCR no browser demora aproximadamente 30 a 120 segundos. Um serviço na nuvem pode demorar 2 a 5 segundos. O compromisso é privacidade versus velocidade.

A Arquitetura: Do Ficheiro ao Resultado

Eis o que acontece quando, por exemplo, comprime um PDF no LuraPDF:

1. Seleção do ficheiro: Arrasta um PDF para a zona de largada. A File API do browser lê o ficheiro para um ArrayBuffer — bytes brutos na memória do browser. Não ocorre nenhum upload.

2. Validação: Uma verificação rápida de que os bytes mágicos %PDF surgem no início do ArrayBuffer.

3. Carregamento: O PDFDocument.load() da pdf-lib analisa a tabela de referências cruzadas, lê a árvore de objetos e constrói uma representação em memória do documento.

4. Enumeração de imagens: A biblioteca percorre os fluxos de conteúdo da página para encontrar XObjects de imagem (imagens incorporadas). A largura, altura, tipo de compressão e dados em bytes de cada imagem são extraídos.

5. Recodificação: Para cada imagem, os dados de pixel brutos são desenhados num elemento HTML Canvas, depois reexportados com um fator de qualidade JPEG mais baixo usando canvas.toBlob('image/jpeg', quality). O objeto de imagem original é substituído pela versão codificada mais pequena.

6. Serialização do documento: O método save() da pdf-lib serializa o documento modificado de volta para bytes. Os fluxos de objetos são comprimidos com DEFLATE.

7. Transferência: Os bytes são encapsulados num objeto Blob, é criado um URL de objeto temporário (URL.createObjectURL(blob)), e um clique programático num <a> aciona o mecanismo de download do browser.

Total de dados transmitidos para qualquer servidor externo: zero bytes.

Web Workers: Manter a Interface Responsiva

O processamento de PDF é intensivo em CPU. Executá-lo na thread JavaScript principal congelaria o separador do browser — não conseguiria deslocar-se, clicar ou ver atualizações de progresso enquanto o ficheiro estava a ser processado.

O LuraPDF executa toda a computação pesada (OCR, análise de PDFs grandes, recodificação de imagens) em Web Workers — threads JavaScript separadas que correm em segundo plano. A thread principal gere a interface, mostra barras de progresso e comunica com o worker através de passagem de mensagens (postMessage / onmessage).

Quando o OCR está em execução, um evento de progresso é acionado após cada página ser processada. O worker envia { page: 5, total: 20, confidence: 94 } para a thread principal, que atualiza a barra de progresso. A sua interface permanece interativa durante todo o processo.

Gestão de Memória

A memória do browser é finita. Um PDF de 200 MB carregado em memória, processado e guardado pode exigir 400 a 600 MB de RAM (bytes originais + dados Canvas intermédios + bytes de saída). Em sistemas com RAM limitada, isto pode desencadear pressão de memória.

Estratégias utilizadas:

• Processamento de páginas em fluxo: Para operações com múltiplas páginas, as páginas são processadas e os elementos Canvas intermédios são descartados após utilização
• URL.revokeObjectURL(): Os URLs de blob temporários são revogados após o download para permitir a recolha de lixo (GC)
• Terminação do worker: Os Web Workers são terminados após concluírem a sua tarefa para recuperar a memória que utilizaram

Para ficheiros muito grandes (>100 MB), os browsers modernos lidam com isto sem problemas em sistemas com 8+ GB de RAM. Sistemas mais antigos ou com memória limitada podem ter dificuldades com ficheiros de origem superiores a 100 MB.

A Arquitetura de Privacidade

O modelo de segurança é imposto pela política de mesma origem do browser e pela arquitetura de isolamento:

• Sem pedidos HTTP: Sem chamadas a APIs externas, sem telemetria, sem chamadas de análise durante o processamento de documentos
• Execução em sandbox: Os Web Workers não podem fazer chamadas de rede para origens externas
• Sem armazenamento persistente: Os ficheiros processados não são escritos no armazenamento do browser (localStorage, IndexedDB ou File System Access)
• Memória com âmbito de separador: Quando fecha o separador, todos os ArrayBuffers e objetos Blob associados a ele são recolhidos pelo garbage collector

Esta arquitetura é verificável: abra o separador Rede nas DevTools do browser enquanto processa um ficheiro. Verá zero pedidos durante a operação de processamento.

Bibliotecas Open-Source: Inspecionáveis, não Caixas Negras

As três bibliotecas principais — pdf-lib, pdfjs-dist e Tesseract.js — são open-source com repositórios públicos no GitHub. As implementações são inspecionáveis por qualquer pessoa. O código de processamento de PDF que corre no LuraPDF não é uma caixa negra proprietária; é código público com utilizadores reais, problemas e contribuições.

Isto é importante para a confiança. Quando um serviço na nuvem diz "processamos e eliminamos os seus ficheiros", está a aceitar a palavra deles. Quando o LuraPDF utiliza bibliotecas open-source numa sandbox de browser sem chamadas de rede, pode verificar a afirmação observando o separador de rede.

Compromissos face ao Processamento na Nuvem

O modelo baseado em browser tem compromissos reais que vale a pena reconhecer com honestidade:

Velocidade: Os serviços na nuvem têm clusters de GPU e infraestrutura dedicada. O OCR no browser num documento grande demora 2 a 10 vezes mais do que um equivalente na nuvem. A compressão é rápida porque utiliza a Canvas API diretamente.

Limites de tamanho de ficheiro: A memória do browser é a restrição. Ficheiros muito grandes (>300 MB) podem atingir limites de memória em alguns sistemas. Os serviços na nuvem não têm essa restrição.

Poder de processamento: O WASM corre a 40 a 80% da velocidade nativa de C++. Os serviços na nuvem executam código nativo otimizado. Para a maioria dos documentos, esta diferença é impercetível; para trabalhos de OCR com mais de 100 páginas, é notória.

Funcionalidades: Algumas funcionalidades avançadas de PDF (verificação de conformidade PDF/X, gestão profissional de cores, fluxos de trabalho CMYK) requerem ferramentas especializadas do lado do servidor. O processamento baseado em browser cobre os 95% dos casos.

Para o processamento quotidiano de documentos — comprimir, unir, assinar, converter, redigir — o modelo baseado em browser é suficientemente rápido, privado por design e não requer conta nem subscrição.

Perguntas Frequentes

O LuraPDF recolhe telemetria ou dados de utilização? O LuraPDF utiliza o Google Analytics para estatísticas agregadas de visualizações de página. As operações de processamento de documentos não geram eventos de análise. O conteúdo dos seus ficheiros nunca é transmitido.

Posso verificar que não ocorre nenhum upload? Sim. Abra as Ferramentas de Programador (F12), clique no separador Rede, filtre por "XHR" ou "Fetch." Processe um ficheiro. Observe zero pedidos de rede relacionados com documentos durante o processamento.

Por que é que o OCR demora tanto em comparação com outros serviços? O Tesseract.js baseado em browser corre na CPU via WebAssembly. Os serviços OCR na nuvem correm em clusters de GPU que processam caracteres muito mais rapidamente. O compromisso é que o seu documento nunca sai do seu browser.

O que acontece se fechar o separador durante o processamento? O processamento para imediatamente. A memória do separador do browser é recolhida pelo garbage collector. O ficheiro original no disco permanece inalterado.

O código é open-source? As bibliotecas de processamento principais (pdf-lib, pdfjs-dist, Tesseract.js) são open-source. O código de interface do LuraPDF não é atualmente open-source, mas a pipeline de processamento utiliza apenas componentes open-source.

A mudança para o processamento de documentos baseado em browser não é um truque. É uma escolha arquitetural genuína com vantagens mensuráveis de privacidade e confiança — ao custo de velocidade em operações intensivas. Para documentos que preferia que não existissem no servidor de outra pessoa, é o compromisso certo.