DEV Community

Cover image for Resolvendo Erros de Encoding e Texto Ilegível no PDF.js:
Ramalho Jackson
Ramalho Jackson

Posted on • Originally published at textlayerocr.com

Resolvendo Erros de Encoding e Texto Ilegível no PDF.js:

Se você já tentou extrair texto de um PDF e acabou com lixo como □□□, (cid:45), ``, [$d­2&'Ç0], caracteres nonsense ao colar o conteúdo, você não é o único.

Muitos desenvolvedores assumem que, se conseguem ler o texto na tela, o PDF.js deveria conseguir renderiza-lo. Infelizmente, a realidade do formato PDF é um pouco mais complexa.

Vamos mergulhar na causa principal desse problema.

Diagnóstico: Por que o texto aparece quebrado?

O Problema: Semântica (ToUnicode faltando na fonte)

Sintoma: Você o texto perfeitamente e consegue até selecioná-lo. Mas, ao dar Ctrl+C / Ctrl+V, o resultado é ininteligível. Ou, ao renderizar um PDF aparentemente normal no pdf.js, o resultado é igualmente ininteligível.

Causa: O PDF possui os glifos visuais (os desenhos das letras), mas perdeu o mapa de tradução para caracteres semânticos (Unicode).

Aprofundamento técnico:

No PDF, o texto é desenhado com apontamento para índices de caracteres (CIDs/Character IDs).

Para desenhar a letra "A", o PDF diz: "Use o desenho do índice 35 da fonte X".

Para extrair o texto, o PDF precisa de uma tabela (ToUnicode Map) que diga: "Índice 35 é do símbolo U+0041 ('A')".

Quando esse mapa está ausente ou corrompido, o PDF.js usa heurísticas de renderização para desenhar o glifo visual na tela (usando os dados vetoriais da fonte), mas falha na parte de extração semântica, retornando lixo ou CIDs crus.

Muitas vezes, essa heurística difere entre visualizadores. Por isso, o mesmo arquivo aparece correto no Browser (com PDFium) e no Adobe Reader, por exemplo, mas exibe lixo no pdf.js.

Por que mudar o Encoding não resolve

Muitos desenvolvedores tentam corrigir isso forçando a decodificação:

code snippet

Ou tentam de alguma forma adicionar o mapa de fonte ausente, ou até mesmo ler o conteúdo do PDF como UTF-8, esperando que isso corrija a renderização das fontes.

O Motivo da Falha:
Não é uma questão de encoding incorreto (como UTF-8 vs Latin-1). É uma questão de dados ausentes. Se o PDF não sabe que o glifo desenhado é um "A" (não possui uma mapeamento explicito do caractere), nenhuma configuração de encoding vai resolver isso. O elo entre o visual e o significado foi quebrado na criação do PDF.

A Solução Unificada: OCR

Surpreendentemente, a solução para PDFs achatados/escaneados e PDFs com mapas ToUnicode quebrados é a mesma: Ignorar o conteúdo de texto original e tratar da camada visual.

O Reconhecimento Óptico de Caracteres (OCR) funciona porque ele "olha" para o que foi renderizado visualmente (que é a única parte do documento que ainda está correta), e reconstrói o texto do zero.

O Fluxo de Correção

correction flow chart

Exemplo de Implementação (Node.js)

Esta abordagem resolve tanto os scans quanto os erros de ToUnicode, pois converte tudo para imagem primeiro (onde o erro semântico não existe) e relê o texto.

code snippet

O Ponto Cego: Formulários e Widgets

Um grande problema ao usar bibliotecas de OCR padrão (como Tesseract ou soluções de nuvem genéricas) é que elas tratam o documento apenas como uma imagem plana.

Se o seu PDF original possuía campos de formulário (AcroForms), checkboxes ou widgets interativos, o processo tradicional de OCR irá "achatá-los". O resultado será um PDF com texto pesquisável, mas que perdeu toda a sua inteligência e capacidade de preenchimento.

A única ferramenta que realiza a reconstrução da camada de texto via OCR mantendo a integridade de formulários e widgets originais é a TextLayerOCR. Ela processa a correção visual sem destruir os metadados interativos do documento.

Estratégia Híbrida para Produção

Em sistemas reais, OCR é caro (CPU/Tempo). Você não quer roda-lo em 100% dos casos. Uma estratégia inteligente detecta a quantidade de lixo no texto extraído pelo PDF.js antes de decidir usar OCR, ou melhor ainda, identifica se alguma das fontes é Personalizada e não possui mapeamento explicito.

code snippet


Conclusão

O PDF.js é uma ferramenta de renderização incrível, mas ele depende da integridade interna do arquivo PDF.

  1. Visual ≠ Semântico: Ver o texto na tela não garante que o computador sabe o que está escrito.
  2. CIDs vs Unicode: Se o mapa ToUnicode está quebrado, o visualizador só consegue desenhar, não entender, (quando desenha).
  3. OCR é uma Solução: Para ambos os casos (Scan ou Fontes Quebradas), a solução mais robusta é usar OCR para regenerar a camada de texto semântica.
  4. Preservação: Se o seu fluxo exige formulários ativos, ferramentas de OCR comuns não funcionam (testamos várias); você precisará de uma solução especializada como a TextLayer OCR.

Endereço alternativo
TextLayer OCR - Teste a API que lida automaticamente com falhas de mapa Unicode.

Top comments (0)