Stirling-PDF: aplicação web local para realizar várias operações em PDFs

Artigo original ↗ Discussão no Hacker News ↗

Ferramentas de PDF auto-hospedadas como o Stirling-PDF estão a ganhar atenção à medida que utilizadores preocupados com a privacidade procuram alternativas a serviços web que exigem o envio de documentos sensíveis. Os comentadores comparam uma vasta gama de opções — desde utilitários de linha de comandos e apps nativas como o Preview do macOS até ferramentas baseadas no navegador e em WASM — salientando compromissos entre facilidade de uso, completude de funcionalidades, consumo excessivo de recursos e suporte multiplataforma. A discussão também aborda problemas mais difíceis de PDFs (análise de formulários, reformatação de layout, marcação, otimização) e nota que, mesmo com uma norma aberta, o ecossistema da Adobe ainda domina muitos casos de uso avançados.

Receção geral e casos de uso

  • Muitos participantes acolhem com agrado uma ferramenta de PDF auto-hospedada e baseada no navegador para evitar enviar documentos sensíveis para sites aleatórios.
  • É particularmente valorizada por utilizadores não técnicos e famílias com vários dispositivos (desktop + mobile) que ainda precisam de uma UI simples.
  • Alguns veem-na como ideal para implementações internas (por exemplo, escritórios, redações) onde muitas pessoas manipulam PDFs com frequência.

Ferramentas e ecossistemas alternativos

  • Ferramentas de linha de comandos: poppler-utils, pdfcpu, pdftk (com relatos de corrupção em alguns servidores Windows), Ghostscript, OCRmyPDF, ImageMagick, wkhtmltopdf, puppeteer/navegadores sem interface.
  • Ferramentas de desktop/SO: o Preview do macOS é repetidamente elogiado pela edição extensa de PDFs; outros mencionam Okular, LibreOffice Draw, Inkscape, Xournal++, Edge, Firefox, vários editores comerciais (Foxit, Nitro, PDF Studio, PDF Expert, Bluebeam, etc.).
  • Ferramentas web / apenas no navegador: pdfsam, pdf24, pdftool.org, smallpdf, Tabula, e vários novos editores/assinadores totalmente no navegador são referidos.

Lacunas de funcionalidades e problemas difíceis de PDFs

  • Funcionalidades desejadas: adicionar/gerir campos de formulário, anexos, marcação/estrutura para acessibilidade, redação, numeração de parágrafos, extração chave–valor de formulários preenchidos, boas ferramentas de reparação e compressão robusta.
  • Vários “problemas difíceis” são apontados:
    • Reformatar PDFs de revistas em várias colunas para Markdown limpo.
    • Extrair dados estruturados de formulários complexos (muitas vezes exigindo OCR + análise de layout).
    • Corrigir problemas estranhos de seleção de texto, em que o PDF pode nem sequer estar realmente “danificado.”
  • Vários contornos envolvem GPT-4 Vision / LLMs, OCR consciente de colunas, pipelines com scripts e otimização baseada em Ghostscript.

Arquitetura: aplicação web vs nativa

  • Um grupo critica correr um servidor web + Docker para operações locais em PDFs, preferindo pequenas ferramentas CLI nativas pela eficiência e por razões ambientais.
  • Outros defendem que as UIs web são mais fáceis de usar e de implementar de forma multiplataforma, especialmente para muitos utilizadores não técnicos; a contentorização simplifica a manutenção em escala.
  • A discussão aborda Electron vs opções mais leves (Tauri, NodeGUI) e abordagens WASM/client-only. A v2 do projeto está planeada para ser, em grande parte, do lado do cliente.

Ecossistema do formato PDF e dos visualizadores

  • Debate sobre o “controlo” da Adobe: o PDF é agora uma norma ISO e amplamente implementada, mas alguns argumentam que apenas o Acrobat suporta de forma fiável toda a especificação complexa (JS, 3D, funcionalidades avançadas).
  • Outros contrapõem que a maioria dos PDFs do mundo real é renderizada sem problemas por ferramentas de terceiros; o PDF/A é destacado para arquivo.
  • O Preview do macOS é amplamente elogiado, mas são referidos bugs conhecidos (por exemplo, operações de assinatura a baralharem a pesquisabilidade do texto) e suporte limitado para funcionalidades scriptadas.

Origens do projeto e roadmap

  • A aplicação terá começado como uma experiência “100% construída com ChatGPT” (site inicial e um punhado de operações) e depois foi amplamente reescrita e expandida manualmente.
  • Atualmente é sustentada por donativos; o mantenedor menciona possíveis funcionalidades pagas/alimentadas por IA no futuro, mas quer que o núcleo continue gratuito.
  • Os planos incluem uma UI mais rica (possivelmente Electron ou semelhante) e uma v2 com forte componente client-side, mantendo ao mesmo tempo uma opção de servidor para uso via API.